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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
