[U-Boot] Release cycle thoughts

[Tom Rini]

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 at 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160529/613ac086/attachment.sig>