Re: [Ksummit-discuss] bug-introducing patches

[Theodore Y. Ts'o]

On Tue, May 08, 2018 at 08:29:14PM +0000, Sasha Levin wrote:
> 
> This is interesting. We have a group of power users who are testing out
> -rc releases, who are usually happy to test out a fast moving target and
> provide helpful reports back. We also have a group who run a -stable
> kernel (-stable build/distro/android/etc) who want to avoid having to
> report bugs to us.
> 
> What we don't have is a group of people who use Linus's actual releases
> (not the -rc stuff, but the actual point releases). Power users will
> move on to the next kernel, and -stable folks won't touch that release
> until there's a corresponding -stable.

Linus doesn't release the point releases.  Those are done by the Greg
K-H and use the same process as does the stable kernels.  The only
difference is that the life point release doesn't last very long; just
until the next kernel release from Linus.

There are probably fewer people who use the point releases compared to
the stable kernels.  But I'd hesitate to call it zero.  We once
assumed that companies were all using Distro kernels, and very few
people used the stable kernels except for distribution channels
(enterprise kernels, BSP kernels, etc.).  Then we discovered that
there are people who use the stable kernel and don't go through the
enterprise distro vendors at all.  It wouldn't surprise me if there
are also a silent (and perhaps large) set of users who take Linus's
releases, and then follow along on the dot releases until the next
release from Linus.

> What if, instead, Linus doesn't actually ever release a point
> release?  We can make the merge window open more often, and since
> there's no actual release, people won't rush to push fixes in later
> -rc cycles.

I dont' understand your proposal.  Linus doesn't actually release
point releases.  Those happen during the -rcX cycle for those people
who are too chicken to follow Linus's tree, and just want the bug
fixes.

Getting rid of the point releases isn't going to change how frequently
the merge window opens.  What would do that is being much more strict
about when we only allow regression fixes only into the tree, so
hopefully the tree stablizes itself by -rc5 or -rc6.  

> Merge window will happen more often, so there's no real reason to
> rush things in a particular window, and since -stable releases every
> week there's no rush to push a fix in since the next release is just
> a week away.

Huh?

I can see shortening the release cycle to a six weeks, instead of our
current 8-9 week cycle.  But after the each cycle where we introduce
new features, during the merge window / integration phase, we do need
to have a time when are fixing regression bugs.

						- Ted