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

[Josh Boyer]

On Wed, Jul 15, 2015 at 12:40 PM, Greg KH <greg at kroah.com> wrote:
> On Wed, Jul 15, 2015 at 12:15:50PM -0400, Sasha Levin wrote:
>> On 07/15/2015 12:03 PM, Greg KH wrote:
>> >> > That would be the ideal setup for me though -- tagged or branched -rc
>> >> > candidates of stable releases that I'd be happy to put through the
>> >> > build/boot test at my end.
>> > kernelci now handles -rc stable releases, so would this just be a
>> > duplication of that work?
>>
>> I've actually suggested -rc stable cycles for the purpose of getting -rc
>> stable kernels into users hands by making it possible for distros to
>> ship these as proposed/test kernels by giving them enough time (right now
>> the review cycle is only a few days, making it impossible for distros
>> to ship them).
>
> Given that I do a new -stable release on the average of one a week,
> getting these into a distro as a testing kernel and getting feedback is
> going to be pretty much impossible.
>
>> As Guenter and Greg mentioned, there's already a fair amount of testing
>> being done on the queue branches, but there's really no testing being
>> done by end users before they receive a final kernel.
>
> I get feedback from Fedora, they always let me know when something goes
> really wrong, which is pretty unusual.  So I don't know if "more
> testing" is going to really pay off.

Well... yes.  We do give feedback, sometimes even other than "oh my
this is broken."  However, our rollout plans tend to skip all the .1
stable releases because we've been bitten a few times in the past with
patches that went into -rc1 that were wrong.  Pretty much the
scenarios being discussed.  So we have held off until .2 comes out to
rebase our releases.

Now, we switched to that a while ago before you started the "must be
in a Linus release" rule, so maybe .1 releases are better now.  We
just don't have data to back it up on the Fedora side though, and I
wanted to be clear on why that is.

Another reason we don't ship .1 releases is because the backlog of
patches is usually huge still, and the prior 4.X-1.y release is
usually still getting updates at this point.  So shipping a .1 rebase
to turn around and ship .2 a week later is a lot of churn for
relatively little gain.  We can get the rebase and the extra patches
in .2 by simply waiting.

josh