Re: [Ksummit-discuss] [CORE TOPIC] Issues with stable process

[Sasha Levin <sasha.levin@oracle.com>]

On 07/13/2015 02:21 PM, Steven Rostedt wrote:
> On Mon, 13 Jul 2015 00:27:52 -0400
> Sasha Levin <sasha.levin@oracle.com> wrote:
> 
> 
>>> Many fixes are important but simply aren't that urgent so the two or
>>> more weeks is no great cost.
>>
>> I'd actually argue that Linus shouldn't be pulling *anything* that wasn't in
>> -next for 2+ weeks. There's no good excuse to want something pulled immediately
>> as the only benefit Linus's tree provides in that aspect is the wider testing
>> it receives, so it would make sense to weed out more bugs in -next before they
>> get to Linus.
> 
> I disagree. I thought next was a place to have integration of new
> development, and not just a place to test. Really, how many people test
> next compared to Linus's tree? I trip over bugs all the times in
> Linus's tree that's been in -next for almost a whole release cycle.

I didn't say that it's not for integration, I just said that with the
recent increase in testing by various people/organizations the focus
seems to be shifting to catching things in -next before they get into
Linus's tree.

> The only bugs that I find that come from -next is integration issues,
> where an interface changes and another subsystem stumbles over it.
> That's exactly what it was for and what it's good at.
> 
> I like the idea that patches marked for stable should sit in Linus's
> tree for at least 2 weeks before being pulled into stable. Linus's tree
> gets the most testing than any other tree and that's where new fixes
> should go.
> 
> 
>>
>> I think that this is a small mind-shift from thinking about Linus's tree as
>> an integration tree to considering it as mostly bug-free code, and stop
>> merging in risky patches. We already have -next for that.
> 
> No, we have -next as a way incorporate new code and see how things
> interact with other subsystems.

I don't see why we're disagreeing?

>>
>>> If a developer/maintainer thinks a fix is urgent, then they need to
>>> explicitly ask for a quick release, and that could be as easy as saying:
>>>
>>>   Cc: stable@vger.kernel.org (URGENT v3.0 and later)
>>>
>>> An 'URGENT' fix *should* come with an independent
>>> "Reviewed-by:"  (well ... everything should of course, but if URGENT
>>> stable patches with no Reviewed-by got some push-back, I think that
>>> would be a "very good thing" all around).
>>
>> I suppose that this is something Linus/maintainers would need to enforce? No
>> patch unless it lived in -next unless it was acked by the maintainer of that
>> subsystem?
>>
>>> I don't think that tightening the criteria for going into any
>>> particular tree will really help.  I'm not sure there is even real
>>> agreement on what is or is not allowed in -stable (we have clearly
>>> written rules, but the practice is really whatever a maintainer
>>> chooses).
>>> -rc prereleases for -stable would only help if people tested them.
>>> Given that the same bugs are in -linus, the testing done there should
>>> be sufficient providing it is given enough time.
>>
>> My reasoning for -rc prereleases for stable was to test out the backports that
>> go into stable kernels: they don't see the light of day until they're shipped
>> out to folks who want *stable* kernels, but end up being the first testers of
>> a backport.
> 
> Which to me looks like rational to let it sit in Linus's tree for a bit.

Backports don't end up in Linus's tree, they only live in our stable trees and
never see the light of day before we ship that tree out.

Thanks,
Sasha

>>
>> I don't want to suggest that we do a few of those per stable kernel, but even
>> one -rc release that would end up in distros (marked as "proposed/devel") and
>> would let users test that would be a great step forward.
>>
>> The reason I've suggested it for Ksummit rather than hashing it out on stable@
>> is that I believe that the solution is more complex and would need more discussion
>> than just slapping a "cooldown period" on patches. We need to make sure less
>> bugs/untested code ends up in Linus's tree to begin with, and we need a way to
>> validate proposed stable releases before releasing them, since -stable users
>> aren't interested in being testers.
> 
> I'm all for discussing this in person.
> 
> -- Steve
>