A lot of the known bugs have fixes which appear to be OK, but haven't
really had enough testing to go in to a -final tree. A lot of them
won't have been tested on SMP boxes for example.
What _would_ be nice would be to have a -$firstinitial$lastinitial
tree that opens up once we get in to the -rc phase - a kind of
'alternative rc' if you like, which collects all the patches that are
rejected for the official -rc tree. That gives the maintainers one
last chance to prove the validity of their patch :-).
Or, to look at it other way, it would be effectively carrying on the
-pre phase during the -rc phase:
E.G. 2.4.22 development could look like this:
2.4.21-final
|
|
V
2.4.22-pre1
|
V
2.4.22-pre2
|
V
[snip]
|
V
2.4.22-pre6
|
V
2.4.22-pre7
| All potential patches are declared
V / here.
2.4.22-rc1-----2.4.22-jb1
| |
V V
2.4.22-rc2 2.4.22-jb2<-Absolutely nothing new goes in from
| | here on, just fixes. If it breaks
V V for more than 1 release, it's
[snip] [snip] permenantly deleted from this -jb
| | tree.
V V
2.4.22-rc5 2.4.22-jb7
| |
V V
2.4.22-rc6<-MERGE---/
| ^
V \--------------- Merge of whatever has survived
2.4.22-rc7<-\ -jb
| ---Delete
V anything that's broken in any way, I.E. it has
2.4.22-final to be perfect.
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/