Re: RFD: Kernel release numbering

[Neil Brown]

On Wednesday March 2, akpm@xxxxxxxx wrote:
> 
> Only davem, AFAIK.  All the other trees get auto-sucked into -mm for
> testing. 

Ok, I got the feeling it was more wide spread than that, but I
apparently misread the signs (people mentioning that had 'patches
queued for Linus' and such).

>           Generally the owners of those trees make the decision as to which
> of their code has been sufficiently well-tested for a Linus merge, and when
> that should happen.

I wonder if there is a problem here.
Who is in a position to judge when a patch is ready to be merged?
I suspect that it would be hard for a developer to be objective about
the readiness of their own patches (I know all my patches are perfectly
ready the moment I create them, despite what experience tells me :-)

Assuming we have a 'stable', a 'testing' and a 'devel' series
(whatever actual numbering gets used for them(*)), then maybe it is ok
for a developer to judge if it is ready for 'testing', but it should
really have either some minimum time in 'testing' or independent
review before being allowed into 'stable'.

Are you and Linus able to handle the independent review load?
Should every developer/maintainer find someone to review any patches
that they think should 'jump the queue'.
(Would anyone like to review my nfs/raid patches for me?  I review
patches I get from others, but find it very hard to review my own
work.  Andrew does a good job, but does miss things sometimes). 

NeilBrown


(*) Options for naming:

Devel              Testing                 Stable
2.ODD.X            2.EVEN.X                2.EVEN.X-ac
2.6.X-mm           2.6.X-rc                2.6.X
2.6.X-mm           2.6.ODD                 2.6.EVEN
2.6.X-mm           2.6.X                   2.6.X + patch addenda <--- my preferred
2.6.X-pre          2.6.X-rc                2.6.X

It doesn't matter much what you call them, but I think the three-way
distinction is needed, and there needs to be a well-understood set of
rules for patches moving from one to the next.

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