Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time

[Guenter Roeck <linux@roeck-us.net>]

On 09/05/2018 07:42 AM, Greg KH wrote:
[ ... ]
> I could do a "one release a week" cycle, which I would _love_ but that
> is not going to decrease the number of patches per release, it is only
> going to make them large (patch rate stays the same, and increases, no
> matter when I release)  So I had been thinking that to break the
> releases up into a "here's a hundred or so patches" per release, was a
> helpful thing to the reviewers.
> 
> If this assumption is incorrect, yes, I can go to one-per-week, if
> people agree that they can handle the large increase per release
> properly.  Can you all do that?
> 

Tough call. More patches per release means higher likelihood of conflicts,
and thus increases the per-release risk (I just checked, chromeos-4.4
carries a whopping 15,000+ patches on top of v4.4.y. Outch). On the other
side, I do miss releases lately, but that is because it sometimes takes
several days for a merge to be accepted by the Chrome OS QC, on top of
the internal merge review process which also takes 2-3 days. Thinking
about it, I'd rather miss a release once in a while than having a rigid
release schedule with more patches per release.

Ultimately, my conclusion is that the current process works fine for us,
but I can also live with fixed schedule. However, I would really dislike
a longer -rc cycle since, for me, it would be zero gain and added pain.

> Are we going to do a "patch tuesday" like our friends in Redmond now? :)
> 
> Note, if we do pick a specific day-per-week, then anything outside of
> that cycle will cause people to look _very_ close at the release.  I
> don't know if that's a good thing or not, but be aware that it could
> cause unintended side-affects.  Personally I think the fact that we are
> _not_ regular is a good thing, no out-of-band information leakage
> happens that way.
> 

Agreed.

Guenter