[U-Boot] Release cycle thoughts
Hey all,
So, when I said a few months back that we would try doing a 2 month release cycle, I planned things out until the v2016.07 release, since that coincided with the old schedule. As I was looking at the ReleaseCycle page today I didn't want to give anyone the wrong impression so I've added in v2016.09 and v2016.11 (and updated the MW for v2016.07 since 05 was late).
At this point I'm happy with the 2 month cycle. Does anyone object and think we should go back to 3 months?
If no one objects there, I'm pondering going up to monthly for 2017 with release generally the first Monday of the month, RCs otherwise on Monday. Shorten the merge window to that first week. But would make planning time easier for everyone.
On Fri, May 27, 2016 at 2:36 PM, Tom Rini trini@konsulko.com wrote:
Hey all,
So, when I said a few months back that we would try doing a 2 month release cycle, I planned things out until the v2016.07 release, since that coincided with the old schedule. As I was looking at the ReleaseCycle page today I didn't want to give anyone the wrong impression so I've added in v2016.09 and v2016.11 (and updated the MW for v2016.07 since 05 was late).
At this point I'm happy with the 2 month cycle. Does anyone object and think we should go back to 3 months?
No objection here, I think it's worked pretty well.
If no one objects there, I'm pondering going up to monthly for 2017 with release generally the first Monday of the month, RCs otherwise on Monday. Shorten the merge window to that first week. But would make planning time easier for everyone.
So presumably a cycle would be a week of merge, two RCs, then GA?
I have a few concerns, I think to make it work we'd need things release bits a bit more stable because some of the things that happened this last cycle would just complete screw it up. * better communication, there were some weeks we didn't have a RC when it was expected, no comms that I saw as to why, release was delayed a week and similarly I didn't see any heads up * guaranteed RCs every time, with concurrent tarballs (eg RC2 didn't get a tar ball until RC3 was already out) * what about quieter months like August (ER summer), Nov (US thanksgiving) and christmas/new year? * some form of CI platform that does the buildman full tests against any pull requests, it seems very manual at the moment which doesn't tend to lend itself to faster cycles.
Peter
On Sat, May 28, 2016 at 10:00:10AM +0100, Peter Robinson wrote:
On Fri, May 27, 2016 at 2:36 PM, Tom Rini trini@konsulko.com wrote:
Hey all,
So, when I said a few months back that we would try doing a 2 month release cycle, I planned things out until the v2016.07 release, since that coincided with the old schedule. As I was looking at the ReleaseCycle page today I didn't want to give anyone the wrong impression so I've added in v2016.09 and v2016.11 (and updated the MW for v2016.07 since 05 was late).
At this point I'm happy with the 2 month cycle. Does anyone object and think we should go back to 3 months?
No objection here, I think it's worked pretty well.
OK, good.
If no one objects there, I'm pondering going up to monthly for 2017 with release generally the first Monday of the month, RCs otherwise on Monday. Shorten the merge window to that first week. But would make planning time easier for everyone.
So presumably a cycle would be a week of merge, two RCs, then GA?
Yes, pretty much.
I have a few concerns, I think to make it work we'd need things release bits a bit more stable because some of the things that happened this last cycle would just complete screw it up.
- better communication, there were some weeks we didn't have a RC when
it was expected, no comms that I saw as to why, release was delayed a week and similarly I didn't see any heads up
- guaranteed RCs every time, with concurrent tarballs (eg RC2 didn't
get a tar ball until RC3 was already out)
Yeah, understood.
- what about quieter months like August (ER summer), Nov (US
thanksgiving) and christmas/new year?
Some releases might end up being "small", but that's OK. I was thinking that if anything, it helps with the "So-and-so was out and missed the window for changes" because there's always the next month release.
- some form of CI platform that does the buildman full tests against
any pull requests, it seems very manual at the moment which doesn't tend to lend itself to faster cycles.
Yes, this is good feedback, thanks. We do have some CI going on after I push things but I also need to get back into some better habits about triggering real hardware tests.
participants (2)
-
Peter Robinson -
Tom Rini