> The reason I mention it is because I've been mulling over something > Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked > at the Q&A session whether we could do a release with just stability > and bug-fixes, and I pooh-poohed it because I didn't see most of us > having the attention span required for that > (cough*cough*moronic*woodland creature*cough*cough).
I'm slightly back, so it's time to get the oar out ;) I think there are two problems 1. It takes a lot of time to identify the stability fixes you need so simply doesn't fit the release cycle. 2. You often need them in the unstable release to work out if they are the right solution. We have several "stable-ish" trees of 3.x.y format. > So I may be pessimistic, but I'd expect many developers would go > "Let's hunt bugs.. Wait. Oooh, shiny" and go off doing some new > feature after all instead. Or just take that release off. A look at some of the bug data shows that is all too true, and also that despite the NSA fiasco and the like we have an awful lot of open, probably real hits in coverity and the like which are effectively widely available to the bad guys to analyse too. > But I do wonder.. Maybe it would be possible, and I'm just unfairly > projecting my own inner squirrel onto other kernel developers. If we > have enough heads-up that people *know* that for one release (and > companies/managers know that too) the only patches that get accepted > are the kind that fix bugs, maybe people really would have sufficient > attention span that it could work. That ought to be happening every release. Every maintainer should be asking "is my tree full of shit that needs cleaning up" and prioritising it, including pushing back on developers to find a good balance between fixing and new stuff. > And the reason I mention "4.0" is that it would be a lovely time to do > that. Roughly a years heads-up that "ok, after 3.19 (or whatever), > we're doing a release with *just* fixes, and then that becomes 4.0". It would be a good time as you went towards it to ask "what code is buggy, problematic and simply not being maintained", and chuck it. It's in the git history so if someone cares in the future they can ressurect it but the tree has a lot of crap in it that slows down other work and simply doesn't matter to anyone. (and if it does them rm -rf is a great way to create new maintainers) It might be very instructive to find the set of devices and archs that are - not looking maintained - not shipped by any vendor anyone has ever heard of - or shipped by every vendor but no users show up in their collected data Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
