Re: [RFC 0/4] Stop maintainer abuse

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Dec 16, 2014 at 01:09:39PM -0500, Jonathan Corbet wrote:
> 
> In general, I worry about trying to codify things too much just because
> different maintainers have different expectations.  As Linus noted, some
> maintainers have their work done by the time the merge window starts and
> can take patches just fine — until something catches fire, at least.

Yeah, I think it's going to be really different pretty much all
maintainers.

Speaking for myself, that's what patchwork is for.  There are plenty
of other times besides merge window when I'm going to be super busy
--- say, because I'm travelling to a conference or for business
reasons.  And those times are far more likely to be hard on me as a
maintainer compared to the merge window.  So everyone's mileage going
to vary widely.

And having a strict schedule like this:

+  kernel.org "mainline:"  |  Patch may appear
+  field when posted       |  in released kernel
+  ------------------------+--------------------------------
+  3.18-rc[1-4]            |  3.19
+  3.18-rc[5-9]            |  3.20
+  3.18                    |  Merge window open - don't post
+  3.19-rc[1-4]            |  3.20
+  3.19-rc[5-9]            |  3.21
+  3.19                    |  Merge window open - don't post
+
+Bug fixes can typically be accepted at any time.

Seems like it's very, VERY bad ju-ju.  I'll take some feature patches
as late as -rc6, if they are simple and I'm confident that regression
testing will catch any problems (because for file systems, very often
xfstests is far more likely to find problems than soak time in
linux-next).

On the flip side, a feature patch, submitted between -rc2 and -rc3,
might not make it because we want more people to look at it, better
benchmarks, etc., etc.  Even a bug fix submitted at that point might
not make it, especially if the bug is extremely rare (and we may have
lived with it for years or decades), and the change is especially
risky/hairy.

So having a schedule like this is very likely going to set all sorts
of false expectations, and may end up causing just as many problems as
it purports to solve.

I wonder if this sort of thing is better placed in various unofficial
documentations which help new users acculturate.  For example, see
some of the slides in the last half of Sarah Sharp's presentation
here:

https://plus.google.com/+SarahSharp/posts/4GSqqGpg8cg

That has the advantage of significantly reducing the risk that things
that originally started out as preferences by a few maintainers
getting turned into bureaucratic rules.

					- Ted