Re: RFD: Kernel release numbering

[Linus Torvalds]

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