Andrew Morton on kernel development

It may be interesting, unless kernel developers ignore the bug-fix only release and work on
new futures by themselves in the meantime.

I preferred the odd/even system we had before 2.6.

I also gave up on reporting kernel bugs. Usually I am the only person with that bug and
hardware 
configuration and nobody will fix it. This is not specific to the kernel though. I think I
never got any 
of the bugs which I reported to fedora, red hat or gnome fixed.

Two other things: is the kernel bugzilla used at all? are there any tests like unit tests to
catch 
regressions for the kernel? both are pretty standard for any other open source project
nowadays. 

I think there's a substantial difference to the way he phrased the suggestion here from what
I've seen before. People tend to think of a bugfix-only release as one in which the mainline
only merges bugfixes. Simply making that policy would almost certainly lead to no more
bugfixes than usual, and twice as many features hitting the following release window.

On the other hand, if the process were driven from the other end, it might work: spend some
period collecting a lot of unfixed bugs, and saturate developers' development time with them,
and, in the cycle after that, there ought to be a lot of bugfixes and no new features, simply
because all that will have matured at the merge window will be bugfixes.

So, if there were a period where there was a campaign to collect long-standing bugs and
regressions against non-recent versions, with the aim of having all of these get resolved in a
particular future version, as the main goal for that release, I think that would be useful.

You don't have to sponsor developers; just send them the misbehaving hardware.  Chances are
good that if it's useful hardware, it'll get fixed.

Yes - Andrew definitely deserves the kudos he gets.

(1) isn't really bug since "make oldconfig" is "expected behavior". Try "make menuconfig" and
see if a menu driven config tool works better for you. Too often, I find the "Help" text
useless and I'm not a kernel newbie. Updating those to be meaningful (e.g. spelling out
uncommon acronyms) would help alot of people.

(2) is a regression and sounds like it's bisect'able. In fact, recent bug on linux-scsi sounds
similar to this though might not be the same:
    http://marc.info/?t=121229388800003&r=1&w=2

So reporting the problem to linux-ide and/or linux-scsi might be a good starting point. You
don't have to report problems to LKML since there are plenty of topic specific mailing lists
that have less traffic. See linux-2.6.25/MAINTAINERS file for the various mailing lists. If
you post to the wrong list, people generally will redirect you to the right one. As Andrew
suggests, be persistent.

Lastly, regarding "being a new newbie" try http://kernelnewbies.org which is one of many
starting points. Usually any help with documentation, code review, or testing is something
anyone with a computer can do - especially if you are finding bugs, willing to report them and
test out (likely bad) theories on the bug. This interaction will lead to learning lots of new
stuff.

Maybe a bit of both?

I've seen previous discussion of this theory before on LWN, along with 
amazement that it hadn't slowed down yet.

There's a number of dynamics in play here of which I'll only consider a 
couple.

The big one is that for many years, Linux was playing catch-up, that is, 
the state-of-the-art in kernel technology was ahead of Linux so far that 
it had to well more than double-time it in ordered to have any hope of 
catching up in something like computer-evolution-reasonable time.  That 
Linux was actually doing it surprised a LOT of people, and was a major 
point behind the SCO suit -- they thought /surely/ IBM or /somebody/ must 
be "cheating", in ordered for Linux to be evolving as incredibly fast as 
it was, toward at that point and for what they were concerned about, a 
real "enterprise" kernel.  Well, we all know where /that/ ended up -- 
there was little if any cheating going on; it was real "organic" growth, 
but at a speed nobody could really account for according to previous 
models, because the Linux model really /is/ different.  At the same time, 
however, it /did/ make us more careful, prompting the introduction of 
better origins documentation and signed-off-by.

In theory, while various (now) peer kernels may still be more mature than 
Linux in some areas, that space is largely gone -- we're caught up, or 
close enough so the speed of change should be slowing down toward that of 
the more mature kernels as we match and now forge into new territory on 
our own.  However, this has been predicted since the late 2.4.teen kernels 
at least, but it just didn't appear to be happening.  In hindsight, we 
weren't as mature as we thought we were back then (a common observation in 
life, I might add, as one advances in years =8^S) and we still had more 
growing to do.

Since the 2.6 series, however, there /have/ been some observable changes 
toward this end.  While the raw volume of change hasn't really slacked off 
yet, the "scariness" of the changes has been decreasing.  The first big 
change from that was the switch from the odd/even cycle.  At first, people 
thought that it'd be relatively temporary, a couple years possibly, before 
something "big and disruptive" enough to all systems to really need an 
alternate development tree in which to coordinate all the changes, forcing 
the opening of a new official development tree.  That hasn't happened.  
We've managed due both to somewhat smaller less-system-wide-disruption 
changes, and an accommodation of more medium-scale changes into the 
ongoing stable kernel.  That this arrangement has continued to work is an 
indication of relative maturity both in featureset and in development team 
and method.  The disruptive scale has been reduced both in absolute terms 
and because we are better able to cope with it in stride than ever before.

That was the first big indication the kernel was maturing, altho raw 
change continued at if anything an increased pace.  A second, more recent 
indication that may or may not prove out over time is the lack 
of "scariness" in now really a couple of kernels in a row.  If the above 
change could be said to mark the transition from large to medium-large 
sized disruption and the ability to handle it, this new one /may/ be the 
first indications of the next level, moving from medium-large to simply 
medium sized change.  It should be noted that while two kernels in a row 
is somewhat notable, it does not a safe trend make as yet.  If we see a 
continuing trend of this thru the end of the year, say a couple more 
kernels in a row, for four, or only three but only one scary one and then 
back to "medium", then it's probably safe to say there's a marked trend.

However, that's nowhere near suggesting that everything has been invented 
now, only that we're finally catching up with the state of the art 
sufficiently, while at the same time enhancing our ability to cope 
in-stride with what might formerly have been disruptive, that things will 
normally slow down a bit as it becomes /us/ that's doing the pioneering, 
breaking the new ground.

Put in the large > med-large > medium language above, that's basically 
saying we might /possibly/ expect one more notch, to medium-small in the 
ordinary case, before we settle into a continuing sustainable pace as the 
new pioneers, where progress is much more hard-fought because nobody's 
been there before.  I don't believe and would actually hope it doesn't 
slow down much beyond that, nor do I believe many people are suggesting 
that it will.  Even then, there are likely to be occasional clusters of 
difficulty and increased change, back into the medium to medium-large zone 
for a kernel or three, before settling back into the medium-small zone.  
However, the prediction is that as we are increasingly doing our own 
pioneering, the average will drop to no higher than medium, with the 
outliers being only medium-large, and large-to-hugely disruptive changes 
will be a thing of the past as on the forefront it tends to be much more 
incremental.

That's my view from this observation point. =8^)

Duncan