Re: RFD: Kernel release numbering

Linus Torvalds
2005-03-03T18:07:09Z

On Thu, 3 Mar 2005, Greg KH wrote:
>
> Then either the patch author splits out the bug if they want to, or we
> punt and say "wait for 2.6.12". Distros can then decide if they want to
> take the whole $big_patch in their releases, if they are near a release
> cycle.

Yes. Exactly.

We're not aiming for "perfect". Just _trying_ to be perfect is what would
kill the whole scheme in the first place. We'd be aiming for "known
rules".

Whether people _agree_ with those rules is then actually not a huge issue.
There will _always_ be things that people don't agree with. Aiming for
consistency is worthwhile in itself.

(Of course, the rules _do_ matter in the sense that there has to be some
point to the consistency. You can have a consistent rule that "the
ChangeLog entries must rhyme", and I think it's a great rule, and I
encourage anybody who wants to to set up such a "rhyming kernel tree", but
that doesn't mean that it makes a lot of difference to people ;).

So havign strict rules that allow _one_ kind of consistency that people
agree is good is a fine idea.

And Adrian, you can always have a different tree that has another set of
rules - and if you use BK you can merge the two and have the "combination
of the rules" tree. The reason I would _stronly_ urge very tight rules is
that if they aren't tight, it ends up having all the problems we've always
seen in other trees.

For example, if the "tight rules tree" allowed reverting an otheriwse good
patch because it had a bug (instead of trying to fix the bug), then I
would never be able to pull that tree into mine. It would take development
_backwards_, and thus it might be sensible for a vendor, but it would
automatically mean that it's not a good base for the next kernel version.

And if I can't just say "ok, I'll always take the 'tight rules' tree",
then we'd get into the forward-and-backward porting hell again, which
would make the whole tree totally pointless. See my point?

Linus