[Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

[Sasha Levin]

On Fri, Sep 07, 2018 at 10:23:28PM +0200, Greg KH wrote:
>On Fri, Sep 07, 2018 at 04:09:46PM +0000, Sasha Levin via Ksummit-discuss wrote:
>> What are your thoughts about a stable-next branch of sorts where we can
>> push stable tagged fixes as soon as they hit either Linus's tree or
>> maybe the pending-fixes branch in linux-next?
>>
>> This way we'll have a longer term stable tree to test, and Greg can just
>> cut releases from there.
>
>No one will pay attention to "stable-next", why would putting something
>there be any different from what I do now?  We run all of the normal
>bots on the stable-rc releases, putting it out for a week longer would
>not cause anything else to happen.

We run bots on stable-rc, but the point I think Laura was trying to make
(and I agree with) is that the 2-3 days of stable-rc isn't enough for
non-bot tests. We'd like to have actual users run stable-rc as well.

So yes, putting it for longer will add a lot more testing.

So the stable-next is just a way for folks to test out new stable
commits without you having to do longer -rc cycles or maintaining extra
trees.

Right now your workflow seems to be:

1. Grab a batch of ~2-3 week old commits from Linus's tree.
2. Review, basic tests and send stable-rc notification.
3. Wait a few days for reviews.
4. Ship it.

The part that's tricky here is that there are only a few days during
step 3 to test out that stable-rc kernel. Not enough for Fedora to let
their testers to get it and play around with.

With a -next branch, this might look something like this:

1. Grab stable tagged commits as they go in Linus's tree and put them on
top of the appropriate stable-next branches (i.e. linux-4.14.y-next).
2. X times a week pick a batch of ~2-3 week old commits, put them in the
-rc branch and send out a review request.
3. Wait a few days for reviews.
4. Ship it.

So it's very similar, but between steps 1 and 2 folks have a chance to
further test out stable commits. This is something that Fedora, for
example, could offer to it's testers as a kernel option.


--
Thanks,
Sasha