Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 02:15 -0800, Andrew Morton wrote:
> If we were to get serious with maintenance of 2.6.x.y streams then that is
> a 100% productisation activity.  It's a very useful activity, and there is
> demand for it.

Correct. That's what -ac and -as kernels try to achieve. Moving those
activities into 2.6.x.y would be easier to understand for users.

> But it is a very different activity.  And a lot of this
> discussion has been getting these two activities confused.

Ack.

> Many people on this mailing list want a super-stable kernel as their first
> (and sometimes only) priority (the product group).  But others have other
> requirements: to make their code avaialble, or to get their hardware
> supported, or to fix that scalability problem (the technology group).  The
> product group's interests are in conflict with the technology group's. 
> 
> There will be no solution to this problem which is completely satisfactory
> to either party.

Right, but moving to the even/odd scheme is worse. Even versions will be
ignored within no time like the -rc versions are now. The result will be
that the "stable" odd releases will be less frequent and the -rc phase
of those will be as hard to sell to testers as the current ones. We will
end up with 2.6.ODD in the same shape as we do now with 2.6.x releases.

Moving to a -preX / rcX scheme might help to convince users to give the
-rc versions a try and help to stabilze for the real release.

What about:
2.6-mm	
2.6-devel
2.6.x-stable

-mm 	bleeding edge
-devel	stabilized from -mm and subsystems
-stable stabilized from devel and real bugfixes

In this case the current -rc scheme could work in a real "release
candidate" scheme. 

The devel tree would not be bound to release cycles and would just
contain ongoing development, so the held back pile of changes is not
growing up in the way it does now.

tglx


-
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/