Linux 3.0?

Posted Sep 4, 2008 17:02 UTC (Thu) by iabervon (subscriber, #722)
Parent article: Linux 3.0?

I think spending 3 months removing things is a bit excessive. I'd say Linus should queue up a set of deprecated code removal patches in a branch, and, when he releases 2.6.30 (or something), merge that branch and release 3.0 fifteen seconds later. This has the big advantage that there's no non-deprecated difference between 2.6.30 and 3.0; so there's no migration pain going from 2.6.30 to 3.0 (aside from the fact that you'll have to have made sure that 2.6.30 isn't giving you any deprecation complaints), and people who have to roll back to 2.6.x because of finding that they're still using a deprecated feature don't have problems going back.

Then there would be a release cycle in which nothing could depend extensively on the deprecated stuff being gone (because there's zero time to write such a change between the 2.6.30 release and the 3.0.1 merge window), meaning that it would be 3.0.2 which people who needed the deprecated stuff really couldn't use (since it would be what includes the "now that that junk is gone, we can clean this code up and move forward" patches). In the 3.0.1 merge window, there would probably be a lot of dropping the parts of patches/merges that fix removed code for API changes (since -next wouldn't account for the removal), but that's easy enough.

Queuing up the actual removal commits for a just-removal release also means that they can be carefully vetted for only removing things that are producing loud warnings already and where exactly what will be removed has been publicized in patch-level detail.

to post comments

RFC: adding a 'version' flag process to kernel development in a non-destructive manner

Posted Sep 5, 2008 1:34 UTC (Fri) by kirkengaard (guest, #15022) [Link] (6 responses)

That may just be the prima-facie-smartest thing I've heard all day, for what it's worth. If the flag for 3.0 is decluttering, then why should it wait on new features, which are currently being added in a perfectly functional process already? Why should it have anything to do with the new feature processes at all? (Besides canonical meaning, which is noticeably flexible)

As we have it now, version.major.minor.micro is a functional system, but we currently only increment 'minor' and 'micro'. We deprecated the system whereby 'major' was incremented, and I'm not sure if there was a system by which 'version' incremented, except by feel. Of course, that's only happened twice.

'minor' increments by stable release cycle timing, measured in release-candidate testing phases and the associated regression-fixing cycle. (Not arguing about operation quality, but the system works, however fuzzy.) 'micro' increments based on regression-fixing during the life of a given stable 'minor' release. Canonically, inferior numbers reset when superior numbers increment. We continue to do this with 'micro', but 'minor' hasn't had a reset since 2.6, when we deprecated the 'major' process. Simple fact, not complaint. Seems to be at least part of the bee in Linus' bonnet.

It isn't necessarily wise to recycle the 'major' number within 2.x, for the simple confusion of what that means -- that's quite another bike-shed altogether, and touchy. Making this cleanup into 2.7, and stabilizing it into 2.8 is like the old pattern, and its replacement is a very profitable minor.micro development/incrementation process. More, we're not talking about doing precisely what we used to do for 'major' increments, but about doing something different, which makes it an inappropriate use of 'major' anyways.

If we develop this argument into a process by which 'version' is incremented based on a desired development goal, in this example cruft-deprecation and removal, this will do several things.

0) it resets the clock on figuring out what to do with 'major' in terms of association with a development process goal.
0.1) it doesn't interfere with the touchy issue of what process *should* be associated with 'major' increments.
1) it adds a process and signal to the overall kernel development environment in pursuit of a desirable goal.
2) it does not remove existing process elements of the overall kernel development environment in pursuit of that goal.
2.1) it does not therefore require redefinition of 'minor' and 'micro' signals, retaining existing meaning along with functionality.

As Mr. Barkalow points out, removal can be run as a git-tree or some similar parallel process, which has its own associated costs. These costs can be mitigated by spending little actual time as a parallel git-tree. Pulling the tree and incrementing 'version' does the job, obviously once the patches/changesets associated have been vetted and tested through normal channels. Voici, a new version, 3.0(.0.0). The -stable process and the normal course of 'minor' updates apply to the new 'version' of Linux just like to the old.

Problem 0) what to do with 2.6.y? The canonical process, of which Marcelo Tosatti was the last victim, was to provide for a new chief maintainer of the previous 'major' branch while development continued in the next 'major' branch. We've since tried doing likewise with 'minor' branches, which experiment was abandoned eventually. The new 'minor' process is now even more forward-oriented than it had been under the old 'major.minor' process.

The real problem is that the less time that 2.6 needs to be run, the better. (Of course, that's the same problem that 2.4->2.6 still has.)

Problem 0.1) what about hardware that won't run under 3.0, and requires 2.6?

There are several remedies for this. One is to set a (preferably conservative) threshold above which hardware is deemed to be worth supporting. This is bound to be unpopular. I'm not sure if there is hardware you can't run 2.6 on -- that's why this is styled an RFC -- but I do know that it works the other way. There is newer hardware that you simply can't run 1.x or 0.x on. I suspect that after 3.0 goes on, however it works, that there will be newer hardware that you simply can't run 2.x on. Which raises:

Problem 1) what, exactly, are we defining as deserving of deprecation?

My understanding, consonant with what I know of the people involved, is that the goal is not to deprecate hardware that works; that's regression, pure and simple. Has been for some time now. The goal is to deprecate code that doesn't work. To remove software 'features' that are no longer required by the current feature-set of the kernel for the support of currently-working hardware. "There is no such thing as obsolete hardware, just hardware somebody else doesn't want." And to do it in a transparent, loud-and-clear manner that doesn't invite easy reversal, while retaining the normal amenities of kernel development (cf. the devfs fiasco).

I'm sure there's plenty in benefits and problems I haven't hit, too. I'm not counting the practical details of ironing out bugs across the transition, or the bugs to be worked out in the precise details of interaction between the two existing and one proposed new processes. Those are surmountable if it's worth doing; someone will have enough of an itch to come up with a good solution.

Fire away!

Matt Frost

(Yes, I'm aware this isn't linux-kernel, sorry.)

RFC: adding a 'version' flag process to kernel development in a non-destructive manner

Posted Sep 5, 2008 15:13 UTC (Fri) by iabervon (subscriber, #722) [Link] (2 responses)

I assume that the stable team would maintain the last 2.6.x.y in parallel with 3.0.0.y (particularly if they're identical aside from 3.0.0.y having chunks removed), and drop it along with 3.0.0.y around when there are no known regressions left in 3.0.1.y.

It should be relatively easy to minimize the stuff that requires 2.6, because the criteria for deprecating something is that either it doesn't exist any more (so far as anybody can tell) or it has a working replacement. If anyone actually can't switch from 2.6 to 3.0, then something from 2.6 needs to be brought back. This is different from 2.4->2.6, where there were a number of things that had to be done in combination with the transition because neither 2.4 nor 2.6 was a superset of the other. If 3.0 is exclusively a feature-removal release, then it's a proper subset of the last 2.6, and if you can get to the last 2.6 and have your system work, and you run without getting deprecation warnings, then you can move to 3.0 without any more changes.

RFC: adding a 'version' flag process to kernel development in a non-destructive manner

Posted Sep 5, 2008 21:11 UTC (Fri) by nix (subscriber, #2304) [Link]

Yeah, but some of the comments in this thread have been talking about
dropping old syscalls and breaking userspace compatibility. Personally I
don't think anyone would care if, say, a.out and all syscalls obsoleted
before the ELF transition stopped working (it happens regularly already
for many kernel releases at a time: Alan Cox was the last person I've
heard of who runs stuff on libc2 and libc3, and even he's stopped now),
but breaking anything from the ELF era is probably a mistake.

RFC: adding a 'version' flag process to kernel development in a non-destructive manner

Posted Jul 2, 2009 18:48 UTC (Thu) by duncan1 (guest, #59412) [Link]

3.0 is exclusively a feature-removal release,
I don't think so. If they are worried about obsolescence or bloat, then they should set a ratio of adding new features to removing obsolete features. Then change the ratio as necessary.

Hobby Horse

Posted Sep 5, 2008 15:55 UTC (Fri) by Baylink (guest, #755) [Link] (2 responses)

<sigh>

Version numbers *mean* something to people, as much as Linus would like to assume they don't.

Lots of people have been numbering lots of software for a long, long time, and the conventions that have sprung up around that happened because they were useful, both to people who assign numbers, and because they were useful to people who need to read them.

It's just like the recent trend of renumbering Interstate exits to match the mile markers: changing the convention provides no *new* information (there were mile markers along the side of the road already, thank-you-very-much) and deprives you of *useful* information that there is now no way to get (did I miss the last Sarasota exit, honey? Hell if I know, dear).

At their base, version numbers are a contract between a user who reports them, and a tech support person who has to know what you're running, and for that purpose, yes, anything will do.

But people, including end users as well as release managers for distributions, make other conventional assumptions about release numbers, to help them make decisions about what they should do in upgrade situations, and breaking those assumptions seems fraught with peril.

Not to mention that if RPM can't manage to figure out that 1.0.0rc5 => 1.0.0 is an *upgrade*, and shouldn't require --force... leading a project to have to name its first production release 1.0.1, how in *hell* should we expect it to handle whatever whacky scheme it is that Linus has in his bikeshed?

No, I don't often think Linus is wrong, and I'm willing to be convinced otherwise, but this is one of those times.

Hobby Horse

Posted Sep 7, 2008 21:13 UTC (Sun) by kirkengaard (guest, #15022) [Link]

Please explain the breakage you imply to the natural upgrade assumptions, making reference to your parent post. Removing cruft *is* an upgrade, AFAICT, and I said nothing that should imply backwards progress linked to forwards numbers. 3.0 will mean something, whatever the process that is linked to that number happens to be. Ripping out cruft is simply the discussed process for calling the 3.0 flag this time.

Also, didn't I explicitly reject reusing the major revision flag for this exact reason?

And, you're misusing bike-shed; the canonical usage which has been followed above is as an object, not a container, and the reference is to what color we'll paint it. Absent that allusion, what are you talking about WRT Linus, numbering, and "wacky schemes" that would violate incremental version-numbering?

[OT] mile markers

Posted Sep 8, 2008 19:52 UTC (Mon) by roelofs (guest, #2599) [Link]

Not in California (much to my amazement).

:-/

Greg