Yocto Project Status WW12’18

Yocto Project Status WW12’18

[Jordan, Robin L]

[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]

Current Dev Position: YP 2.5 M3 final close out.

Next Deadline: YP 2.5 M3 cut off was 2/19/18

*** FEATURE FREEZE for 2.5 has passed ***


SWAT lead is currently Ross.

SWAT team rotation: Armin -> Ross on March 23, 2018

SWAT team rotation: Ross -> Juro on March 30, 2018

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

  *   YP 2.4.2 was released: https://lists.yoctoproject.org/pipermail/yocto/2018-March/040282.html
  *   Meta-intel 8.1 was released: https://lists.yoctoproject.org/pipermail/meta-intel/2018-March/005261.html
  *   We’ve realised we were going to run into problems with distros adopting glibc 2.27, if not now, during the next release cycle. We therefore decided to head off this problem and try and fix the issues now. Unfortunately, due to locale changes in 2.27, it also breaks our eSDK in the current and all previous releases. We have fixes in master for this (thanks Ross!) and backports ready for rocko and pyro in the -next branches. Morty is proving harder to fix. We believe it is likely better to fix these issue even if the changes are invasive (they are at least mostly contained to the SDKs).

  *   The gcc 6.x changes were merged into rocko/pyro/morty which means point releases are now unblocked by that issue.
  *   The performance issue reported last week was tracked down to a kernel change which was reverted.
  *   The new buildbot autobuilder instance is working with basic functionality. We therefore plan to run the M3 release build on that infrastructure with a view to using it for the main 2.5 release. It was great to be able to report an issue upstream and be using their latest code! The autobuilder functionality is improved in at least two significant ways already which benefit the maintainers.
  *   We really do need to roll M3 now, our current plan is to test the final changes in mut and then run M3 with this. It is not a perfect set of features, many things simply haven’t made it in as the people doing review are overloaded. We’re too far past the freeze deadline to realistically make any further progress with this though.
  *   ELC was productive and there was a lot of good discussion between the people there about many different things. In particular we have some ideas for improving the project’s build infrastructure to allow more builds including other layers. More info will follow as we build the plans to make that happen.


Planned upcoming dot releases:

YP 2.3.4 (Pyro) will be built after 2.5 M3

YP 2.2.4 (Morty) will be built after 2.5 M3 once the glibc 2.27 issue is fixed

YP 2.4.3 (Rocko) is planned for post YP 2.5.


Key YP 2.5 Dates are:

YP 2.5 M3 is in feature freeze.  See status above.

YP 2.5 M3 was scheduled for release 3/2/18

YP 2.5 M4 cut off of 4/2/18

YP 2.5 M4 release of 4/27/18


Tracking Metrics:

            WDD 2673 (last week 2673)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features


The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]





Robin Jordan

Yocto Project Program Manager


[-- Attachment #2: Type: text/html, Size: 16558 bytes --]

Re: [OE-core] Yocto Project Status WW12’18

[akuster808]

[-- Attachment #1: Type: text/plain, Size: 4015 bytes --]



On 03/19/2018 08:45 AM, Jordan, Robin L wrote:
>
> Current Dev Position: YP 2.5 M3 final close out.
>
> Next Deadline: YP 2.5 M3 cut off was 2/19/18
>
> *** FEATURE FREEZE for 2.5 has passed ***
>
>  
>
> SWAT lead is currently Ross.
>
> SWAT team rotation: Armin -> Ross on March 23, 2018
>
> SWAT team rotation: Ross -> Juro on March 30, 2018
>
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Key Status/Updates:
>
>   * YP 2.4.2 was released:
>     https://lists.yoctoproject.org/pipermail/yocto/2018-March/040282.html
>   * Meta-intel 8.1 was released:
>     https://lists.yoctoproject.org/pipermail/meta-intel/2018-March/005261.html
>
>   * We’ve realised we were going to run into problems with distros
>     adopting glibc 2.27, if not now, during the next release cycle. We
>     therefore decided to head off this problem and try and fix the
>     issues now. Unfortunately, due to locale changes in 2.27, it also
>     breaks our eSDK in the current and all previous releases. We have
>     fixes in master for this (thanks Ross!) and backports ready for
>     rocko and pyro in the -next branches. Morty is proving harder to
>     fix. We believe it is likely better to fix these issue even if the
>     changes are invasive (they are at least mostly contained to the SDKs).
>
>   * The gcc 6.x changes were merged into rocko/pyro/morty which means
>     point releases are now unblocked by that issue.
>   * The performance issue reported last week was tracked down to a
>     kernel change which was reverted.
>   * The new buildbot autobuilder instance is working with basic
>     functionality. We therefore plan to run the M3 release build on
>     that infrastructure with a view to using it for the main 2.5
>     release. It was great to be able to report an issue upstream and
>     be using their latest code! The autobuilder functionality is
>     improved in at least two significant ways already which benefit
>     the maintainers.
>   * We really do need to roll M3 now, our current plan is to test the
>     final changes in mut and then run M3 with this. It is not a
>     perfect set of features, many things simply haven’t made it in as
>     the people doing review are overloaded. We’re too far past the
>     freeze deadline to realistically make any further progress with
>     this though.
>   * ELC was productive and there was a lot of good discussion between
>     the people there about many different things. In particular we
>     have some ideas for improving the project’s build infrastructure
>     to allow more builds including other layers. More info will follow
>     as we build the plans to make that happen.
>
>  
>
> Planned upcoming dot releases:
>
> YP 2.3.4 (Pyro) will be built after 2.5 M3
>
> YP 2.2.4 (Morty) will be built after 2.5 M3 once the glibc 2.27 issue
> is fixed
>
> YP 2.4.3 (Rocko) is planned for post YP 2.5.
>
>  
>
> Key YP 2.5 Dates are:
>
> YP 2.5 M3 is in feature freeze.  See status above.
>
Does this include package updates?

Do we have a place identified for new changes (2.6) while 2.5 stabilizes.

- armin


> YP 2.5 M3 was scheduled for release 3/2/18
>
> YP 2.5 M4 cut off of 4/2/18
>
> YP 2.5 M4 release of 4/27/18
>
>  
>
> Tracking Metrics:
>
>             WDD 2673 (last week 2673)
>
> (https://wiki.yoctoproject.org/charts/combo.html)
>
>  
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features
>
>  
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>  
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>  
>
>  
>
> Robin Jordan
>
> Yocto Project Program Manager
>
>  
>
>
>


[-- Attachment #2: Type: text/html, Size: 19574 bytes --]

Re: Yocto Project Status WW12’18

[akuster808]

[-- Attachment #1: Type: text/plain, Size: 4015 bytes --]



On 03/19/2018 08:45 AM, Jordan, Robin L wrote:
>
> Current Dev Position: YP 2.5 M3 final close out.
>
> Next Deadline: YP 2.5 M3 cut off was 2/19/18
>
> *** FEATURE FREEZE for 2.5 has passed ***
>
>  
>
> SWAT lead is currently Ross.
>
> SWAT team rotation: Armin -> Ross on March 23, 2018
>
> SWAT team rotation: Ross -> Juro on March 30, 2018
>
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Key Status/Updates:
>
>   * YP 2.4.2 was released:
>     https://lists.yoctoproject.org/pipermail/yocto/2018-March/040282.html
>   * Meta-intel 8.1 was released:
>     https://lists.yoctoproject.org/pipermail/meta-intel/2018-March/005261.html
>
>   * We’ve realised we were going to run into problems with distros
>     adopting glibc 2.27, if not now, during the next release cycle. We
>     therefore decided to head off this problem and try and fix the
>     issues now. Unfortunately, due to locale changes in 2.27, it also
>     breaks our eSDK in the current and all previous releases. We have
>     fixes in master for this (thanks Ross!) and backports ready for
>     rocko and pyro in the -next branches. Morty is proving harder to
>     fix. We believe it is likely better to fix these issue even if the
>     changes are invasive (they are at least mostly contained to the SDKs).
>
>   * The gcc 6.x changes were merged into rocko/pyro/morty which means
>     point releases are now unblocked by that issue.
>   * The performance issue reported last week was tracked down to a
>     kernel change which was reverted.
>   * The new buildbot autobuilder instance is working with basic
>     functionality. We therefore plan to run the M3 release build on
>     that infrastructure with a view to using it for the main 2.5
>     release. It was great to be able to report an issue upstream and
>     be using their latest code! The autobuilder functionality is
>     improved in at least two significant ways already which benefit
>     the maintainers.
>   * We really do need to roll M3 now, our current plan is to test the
>     final changes in mut and then run M3 with this. It is not a
>     perfect set of features, many things simply haven’t made it in as
>     the people doing review are overloaded. We’re too far past the
>     freeze deadline to realistically make any further progress with
>     this though.
>   * ELC was productive and there was a lot of good discussion between
>     the people there about many different things. In particular we
>     have some ideas for improving the project’s build infrastructure
>     to allow more builds including other layers. More info will follow
>     as we build the plans to make that happen.
>
>  
>
> Planned upcoming dot releases:
>
> YP 2.3.4 (Pyro) will be built after 2.5 M3
>
> YP 2.2.4 (Morty) will be built after 2.5 M3 once the glibc 2.27 issue
> is fixed
>
> YP 2.4.3 (Rocko) is planned for post YP 2.5.
>
>  
>
> Key YP 2.5 Dates are:
>
> YP 2.5 M3 is in feature freeze.  See status above.
>
Does this include package updates?

Do we have a place identified for new changes (2.6) while 2.5 stabilizes.

- armin


> YP 2.5 M3 was scheduled for release 3/2/18
>
> YP 2.5 M4 cut off of 4/2/18
>
> YP 2.5 M4 release of 4/27/18
>
>  
>
> Tracking Metrics:
>
>             WDD 2673 (last week 2673)
>
> (https://wiki.yoctoproject.org/charts/combo.html)
>
>  
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features
>
>  
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>  
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>  
>
>  
>
> Robin Jordan
>
> Yocto Project Program Manager
>
>  
>
>
>


[-- Attachment #2: Type: text/html, Size: 19574 bytes --]

Re: [OE-core] Yocto Project Status WW12’18

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On 19 March 2018 at 19:22, akuster808 <akuster808@gmail.com> wrote:

> YP 2.5 M3 is in feature freeze.  See status above.
>
> Does this include package updates?
>

Yes, upgrades count as features.


> Do we have a place identified for new changes (2.6) while 2.5 stabilizes.
>

A formal place, no.  I tend to queue stuff in a branch if master isn't
taking all of my energy, otherwise the patches will sit on the list until
2.5 releases.  Typically master and sumo branches won't diverge until
post-release.

Ross

[-- Attachment #2: Type: text/html, Size: 1404 bytes --]

Re: Yocto Project Status WW12’18

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On 19 March 2018 at 19:22, akuster808 <akuster808@gmail.com> wrote:

> YP 2.5 M3 is in feature freeze.  See status above.
>
> Does this include package updates?
>

Yes, upgrades count as features.


> Do we have a place identified for new changes (2.6) while 2.5 stabilizes.
>

A formal place, no.  I tend to queue stuff in a branch if master isn't
taking all of my energy, otherwise the patches will sit on the list until
2.5 releases.  Typically master and sumo branches won't diverge until
post-release.

Ross

[-- Attachment #2: Type: text/html, Size: 1404 bytes --]

Re: [OE-core] Yocto Project Status WW12’18

[Alexander Kanavin]

On 03/19/2018 10:07 PM, Burton, Ross wrote:
>     Do we have a place identified for new changes (2.6) while 2.5
>     stabilizes.
> 
> 
> A formal place, no.  I tend to queue stuff in a branch if master isn't 
> taking all of my energy, otherwise the patches will sit on the list 
> until 2.5 releases.  Typically master and sumo branches won't diverge 
> until post-release.

Which brings me to a question: what is a good schedule and cadence for 
AUH runs? Currently it's run on the 15th of every odd-numbered month (so 
January, March, and so on), but I thought of shifting it one month 
forward, so it doesn't land right in the middle of a feature freeze. 
Thoughts?

Alex

Re: [yocto] Yocto Project Status WW12’18

[Alexander Kanavin]

On 03/19/2018 10:07 PM, Burton, Ross wrote:
>     Do we have a place identified for new changes (2.6) while 2.5
>     stabilizes.
> 
> 
> A formal place, no.  I tend to queue stuff in a branch if master isn't 
> taking all of my energy, otherwise the patches will sit on the list 
> until 2.5 releases.  Typically master and sumo branches won't diverge 
> until post-release.

Which brings me to a question: what is a good schedule and cadence for 
AUH runs? Currently it's run on the 15th of every odd-numbered month (so 
January, March, and so on), but I thought of shifting it one month 
forward, so it doesn't land right in the middle of a feature freeze. 
Thoughts?

Alex

Re: [OE-core] Yocto Project Status WW12’18

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On 20 March 2018 at 10:07, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 03/19/2018 10:07 PM, Burton, Ross wrote:
>
>>     Do we have a place identified for new changes (2.6) while 2.5
>>     stabilizes.
>>
>>
>> A formal place, no.  I tend to queue stuff in a branch if master isn't
>> taking all of my energy, otherwise the patches will sit on the list until
>> 2.5 releases.  Typically master and sumo branches won't diverge until
>> post-release.
>>
>
> Which brings me to a question: what is a good schedule and cadence for AUH
> runs? Currently it's run on the 15th of every odd-numbered month (so
> January, March, and so on), but I thought of shifting it one month forward,
> so it doesn't land right in the middle of a feature freeze. Thoughts?
>

How long does a single run take, and why not run it every month?

Ross

[-- Attachment #2: Type: text/html, Size: 1362 bytes --]

Re: [yocto] Yocto Project Status WW12’18

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On 20 March 2018 at 10:07, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 03/19/2018 10:07 PM, Burton, Ross wrote:
>
>>     Do we have a place identified for new changes (2.6) while 2.5
>>     stabilizes.
>>
>>
>> A formal place, no.  I tend to queue stuff in a branch if master isn't
>> taking all of my energy, otherwise the patches will sit on the list until
>> 2.5 releases.  Typically master and sumo branches won't diverge until
>> post-release.
>>
>
> Which brings me to a question: what is a good schedule and cadence for AUH
> runs? Currently it's run on the 15th of every odd-numbered month (so
> January, March, and so on), but I thought of shifting it one month forward,
> so it doesn't land right in the middle of a feature freeze. Thoughts?
>

How long does a single run take, and why not run it every month?

Ross

[-- Attachment #2: Type: text/html, Size: 1362 bytes --]

Re: [OE-core] Yocto Project Status WW12’18

[Alexander Kanavin]

On 03/20/2018 12:52 PM, Burton, Ross wrote:
>     Which brings me to a question: what is a good schedule and cadence
>     for AUH runs? Currently it's run on the 15th of every odd-numbered
>     month (so January, March, and so on), but I thought of shifting it
>     one month forward, so it doesn't land right in the middle of a
>     feature freeze. Thoughts?
> 
> 
> How long does a single run take, and why not run it every month?

Just a bit longer than a day, maybe 30 hours, if it needs to update the 
typical amount of 100-150 packages. I'll shift it to monthly then.

Alex

Re: [yocto] Yocto Project Status WW12’18

[Alexander Kanavin]

On 03/20/2018 12:52 PM, Burton, Ross wrote:
>     Which brings me to a question: what is a good schedule and cadence
>     for AUH runs? Currently it's run on the 15th of every odd-numbered
>     month (so January, March, and so on), but I thought of shifting it
>     one month forward, so it doesn't land right in the middle of a
>     feature freeze. Thoughts?
> 
> 
> How long does a single run take, and why not run it every month?

Just a bit longer than a day, maybe 30 hours, if it needs to update the 
typical amount of 100-150 packages. I'll shift it to monthly then.

Alex

Re: [OE-core] Yocto Project Status WW12’18

[Richard Purdie]

On Tue, 2018-03-20 at 13:26 +0200, Alexander Kanavin wrote:
> On 03/20/2018 12:52 PM, Burton, Ross wrote:
> > 
> >     Which brings me to a question: what is a good schedule and
> > cadence
> >     for AUH runs? Currently it's run on the 15th of every odd-
> > numbered
> >     month (so January, March, and so on), but I thought of shifting
> > it
> >     one month forward, so it doesn't land right in the middle of a
> >     feature freeze. Thoughts?
> > 
> > 
> > How long does a single run take, and why not run it every month?
> Just a bit longer than a day, maybe 30 hours, if it needs to update
> the 
> typical amount of 100-150 packages. I'll shift it to monthly then.

Personally I'm leaning to every couple of weeks...

Cheers,

Richard

Re: [yocto] Yocto Project Status WW12’18

[Richard Purdie]

On Tue, 2018-03-20 at 13:26 +0200, Alexander Kanavin wrote:
> On 03/20/2018 12:52 PM, Burton, Ross wrote:
> > 
> >     Which brings me to a question: what is a good schedule and
> > cadence
> >     for AUH runs? Currently it's run on the 15th of every odd-
> > numbered
> >     month (so January, March, and so on), but I thought of shifting
> > it
> >     one month forward, so it doesn't land right in the middle of a
> >     feature freeze. Thoughts?
> > 
> > 
> > How long does a single run take, and why not run it every month?
> Just a bit longer than a day, maybe 30 hours, if it needs to update
> the 
> typical amount of 100-150 packages. I'll shift it to monthly then.

Personally I'm leaning to every couple of weeks...

Cheers,

Richard

Re: [OE-core] Yocto Project Status WW12’18

[Alexander Kanavin]

On 03/20/2018 05:59 PM, Richard Purdie wrote:
>>> How long does a single run take, and why not run it every month?
>> Just a bit longer than a day, maybe 30 hours, if it needs to update
>> the
>> typical amount of 100-150 packages. I'll shift it to monthly then.
> 
> Personally I'm leaning to every couple of weeks...

My worry is that shorter AUH periods will lead to reminder fatigue. Also 
the period between submitting the updates, and having them show up in 
master is sometimes less than ideal, even when the freeze is not in effect.

Alex

Re: [yocto] Yocto Project Status WW12’18

[Alexander Kanavin]

On 03/20/2018 05:59 PM, Richard Purdie wrote:
>>> How long does a single run take, and why not run it every month?
>> Just a bit longer than a day, maybe 30 hours, if it needs to update
>> the
>> typical amount of 100-150 packages. I'll shift it to monthly then.
> 
> Personally I'm leaning to every couple of weeks...

My worry is that shorter AUH periods will lead to reminder fatigue. Also 
the period between submitting the updates, and having them show up in 
master is sometimes less than ideal, even when the freeze is not in effect.

Alex

Re: [OE-core] Yocto Project Status WW12’18

[Tim Orling]

> On Mar 20, 2018, at 11:00 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> 
> On 03/20/2018 05:59 PM, Richard Purdie wrote:
>>>> How long does a single run take, and why not run it every month?
>>> Just a bit longer than a day, maybe 30 hours, if it needs to update
>>> the
>>> typical amount of 100-150 packages. I'll shift it to monthly then.
>> Personally I'm leaning to every couple of weeks...
> 
> My worry is that shorter AUH periods will lead to reminder fatigue. Also the period between submitting the updates, and having them show up in master is sometimes less than ideal, even when the freeze is not in effect.
> 

I agree with both of you. I guess that makes me a transistor that can’t decide which path to choose :)

For meta-perl and meta-python, I am striving to run once a week, but that isn’t intended to send email out to any maintainers, it is just for my own accounting. It gets very messy with in-flight patches, which I hope to fix by using git-pw to not include packages that already have an upgrade in review. It is also optimistic for me to personally fix the 20+ packages that need updates at any given moment. This is why I need run time testing to give me better confidence in auto-upgraded recipes. Working on it :)

> Alex
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [yocto] Yocto Project Status WW12’18

[Tim Orling]

> On Mar 20, 2018, at 11:00 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> 
> On 03/20/2018 05:59 PM, Richard Purdie wrote:
>>>> How long does a single run take, and why not run it every month?
>>> Just a bit longer than a day, maybe 30 hours, if it needs to update
>>> the
>>> typical amount of 100-150 packages. I'll shift it to monthly then.
>> Personally I'm leaning to every couple of weeks...
> 
> My worry is that shorter AUH periods will lead to reminder fatigue. Also the period between submitting the updates, and having them show up in master is sometimes less than ideal, even when the freeze is not in effect.
> 

I agree with both of you. I guess that makes me a transistor that can’t decide which path to choose :)

For meta-perl and meta-python, I am striving to run once a week, but that isn’t intended to send email out to any maintainers, it is just for my own accounting. It gets very messy with in-flight patches, which I hope to fix by using git-pw to not include packages that already have an upgrade in review. It is also optimistic for me to personally fix the 20+ packages that need updates at any given moment. This is why I need run time testing to give me better confidence in auto-upgraded recipes. Working on it :)

> Alex
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Yocto Project Status WW12’18

[Philip Balister]

On 03/20/2018 05:26 AM, Alexander Kanavin wrote:
> On 03/20/2018 12:52 PM, Burton, Ross wrote:
>>     Which brings me to a question: what is a good schedule and cadence
>>     for AUH runs? Currently it's run on the 15th of every odd-numbered
>>     month (so January, March, and so on), but I thought of shifting it
>>     one month forward, so it doesn't land right in the middle of a
>>     feature freeze. Thoughts?
>>
>>
>> How long does a single run take, and why not run it every month?
> 
> Just a bit longer than a day, maybe 30 hours, if it needs to update the
> typical amount of 100-150 packages. I'll shift it to monthly then.

Maybe bi-weekly? Could that help reduce the number of upgrades needed
for each run?

Philip

Re: [yocto] Yocto Project Status WW12’18

[Philip Balister]

On 03/20/2018 05:26 AM, Alexander Kanavin wrote:
> On 03/20/2018 12:52 PM, Burton, Ross wrote:
>>     Which brings me to a question: what is a good schedule and cadence
>>     for AUH runs? Currently it's run on the 15th of every odd-numbered
>>     month (so January, March, and so on), but I thought of shifting it
>>     one month forward, so it doesn't land right in the middle of a
>>     feature freeze. Thoughts?
>>
>>
>> How long does a single run take, and why not run it every month?
> 
> Just a bit longer than a day, maybe 30 hours, if it needs to update the
> typical amount of 100-150 packages. I'll shift it to monthly then.

Maybe bi-weekly? Could that help reduce the number of upgrades needed
for each run?

Philip

Re: [OE-core] Yocto Project Status WW12’18

[Alexander Kanavin]

On 03/21/2018 04:24 PM, Philip Balister wrote:
>>>      Which brings me to a question: what is a good schedule and cadence
>>>      for AUH runs? Currently it's run on the 15th of every odd-numbered
>>>      month (so January, March, and so on), but I thought of shifting it
>>>      one month forward, so it doesn't land right in the middle of a
>>>      feature freeze. Thoughts?
>>>
>>>
>>> How long does a single run take, and why not run it every month?
>>
>> Just a bit longer than a day, maybe 30 hours, if it needs to update the
>> typical amount of 100-150 packages. I'll shift it to monthly then.
> 
> Maybe bi-weekly? Could that help reduce the number of upgrades needed
> for each run?

Only if the maintainers take those reminders as high priority items, and 
actually send out the patches quickly, and then those patches make it to 
master. All that needs to happen within those two weeks. Otherwise, the 
AUH will just re-run the same set.

Alex

Re: [yocto] Yocto Project Status WW12’18

[Alexander Kanavin]

On 03/21/2018 04:24 PM, Philip Balister wrote:
>>>      Which brings me to a question: what is a good schedule and cadence
>>>      for AUH runs? Currently it's run on the 15th of every odd-numbered
>>>      month (so January, March, and so on), but I thought of shifting it
>>>      one month forward, so it doesn't land right in the middle of a
>>>      feature freeze. Thoughts?
>>>
>>>
>>> How long does a single run take, and why not run it every month?
>>
>> Just a bit longer than a day, maybe 30 hours, if it needs to update the
>> typical amount of 100-150 packages. I'll shift it to monthly then.
> 
> Maybe bi-weekly? Could that help reduce the number of upgrades needed
> for each run?

Only if the maintainers take those reminders as high priority items, and 
actually send out the patches quickly, and then those patches make it to 
master. All that needs to happen within those two weeks. Otherwise, the 
AUH will just re-run the same set.

Alex

Re: [OE-core] Yocto Project Status WW12’18

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

Monthly seems like a good enough cadence to give everyone time to review
the mails, send the mails, get reviewed on the list, go through the
autobuilder, and eventually reach master.  Too fast and AUH will be sending
nagging mails for a patch which is shortly being merged.

Can we stop bikeshedding now? :)

Ross

On 21 March 2018 at 14:31, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 03/21/2018 04:24 PM, Philip Balister wrote:
>
>>      Which brings me to a question: what is a good schedule and cadence
>>>>      for AUH runs? Currently it's run on the 15th of every odd-numbered
>>>>      month (so January, March, and so on), but I thought of shifting it
>>>>      one month forward, so it doesn't land right in the middle of a
>>>>      feature freeze. Thoughts?
>>>>
>>>>
>>>> How long does a single run take, and why not run it every month?
>>>>
>>>
>>> Just a bit longer than a day, maybe 30 hours, if it needs to update the
>>> typical amount of 100-150 packages. I'll shift it to monthly then.
>>>
>>
>> Maybe bi-weekly? Could that help reduce the number of upgrades needed
>> for each run?
>>
>
> Only if the maintainers take those reminders as high priority items, and
> actually send out the patches quickly, and then those patches make it to
> master. All that needs to happen within those two weeks. Otherwise, the AUH
> will just re-run the same set.
>
> Alex
>

[-- Attachment #2: Type: text/html, Size: 2177 bytes --]

Re: [yocto] Yocto Project Status WW12’18

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

Monthly seems like a good enough cadence to give everyone time to review
the mails, send the mails, get reviewed on the list, go through the
autobuilder, and eventually reach master.  Too fast and AUH will be sending
nagging mails for a patch which is shortly being merged.

Can we stop bikeshedding now? :)

Ross

On 21 March 2018 at 14:31, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 03/21/2018 04:24 PM, Philip Balister wrote:
>
>>      Which brings me to a question: what is a good schedule and cadence
>>>>      for AUH runs? Currently it's run on the 15th of every odd-numbered
>>>>      month (so January, March, and so on), but I thought of shifting it
>>>>      one month forward, so it doesn't land right in the middle of a
>>>>      feature freeze. Thoughts?
>>>>
>>>>
>>>> How long does a single run take, and why not run it every month?
>>>>
>>>
>>> Just a bit longer than a day, maybe 30 hours, if it needs to update the
>>> typical amount of 100-150 packages. I'll shift it to monthly then.
>>>
>>
>> Maybe bi-weekly? Could that help reduce the number of upgrades needed
>> for each run?
>>
>
> Only if the maintainers take those reminders as high priority items, and
> actually send out the patches quickly, and then those patches make it to
> master. All that needs to happen within those two weeks. Otherwise, the AUH
> will just re-run the same set.
>
> Alex
>

[-- Attachment #2: Type: text/html, Size: 2177 bytes --]

Re: [OE-core] Yocto Project Status WW12’18

[Richard Purdie]

On Tue, 2018-03-20 at 20:00 +0200, Alexander Kanavin wrote:
> On 03/20/2018 05:59 PM, Richard Purdie wrote:
> > 
> > > 
> > > > 
> > > > How long does a single run take, and why not run it every
> > > > month?
> > > Just a bit longer than a day, maybe 30 hours, if it needs to
> > > update
> > > the
> > > typical amount of 100-150 packages. I'll shift it to monthly
> > > then.
> > Personally I'm leaning to every couple of weeks...
> My worry is that shorter AUH periods will lead to reminder fatigue.
> Also the period between submitting the updates, and having them show
> up in master is sometimes less than ideal, even when the freeze is
> not in effect.

Its a valid concern? Once every three weeks? I would like to make
things more available for people if possible too...

With builds we've had a bad run at the moment and am hoping with
improvements in build resources that are in process we can fix that.

Cheers,

Richard

Re: [yocto] Yocto Project Status WW12’18

[Richard Purdie]

On Tue, 2018-03-20 at 20:00 +0200, Alexander Kanavin wrote:
> On 03/20/2018 05:59 PM, Richard Purdie wrote:
> > 
> > > 
> > > > 
> > > > How long does a single run take, and why not run it every
> > > > month?
> > > Just a bit longer than a day, maybe 30 hours, if it needs to
> > > update
> > > the
> > > typical amount of 100-150 packages. I'll shift it to monthly
> > > then.
> > Personally I'm leaning to every couple of weeks...
> My worry is that shorter AUH periods will lead to reminder fatigue.
> Also the period between submitting the updates, and having them show
> up in master is sometimes less than ideal, even when the freeze is
> not in effect.

Its a valid concern? Once every three weeks? I would like to make
things more available for people if possible too...

With builds we've had a bad run at the moment and am hoping with
improvements in build resources that are in process we can fix that.

Cheers,

Richard