Messages in this thread | | | From | Neil Brown <> | Date | Thu, 3 Mar 2005 11:11:42 +1100 | Subject | Re: RFD: Kernel release numbering |
| |
If I understand you correctly, what you are effectively saying is that people don't test the -rc releases enough, so you are going to start giving these releases a more formal name: 2.6.ODD. That will encourage more people to test them, so that when you do a real release (now called 2.6.EVEN instead of 2.6.X), it will be more stable.
I don't buy this. You won't fool anyone. People will just start using the .EVEN releases and you won't get any more testing than you currently do.
A different approach would be to not release a 'stable' kernel at all, but rather release 'fixup' patches. i.e. you release 2.6.X as a 'testing' kernel and then start work on 2.6.X+1. When a patch comes along that fixes a *real*problem* in 2.6.X, you add that to a list of addenda for 2.6.X. People who run 2.6.X can monitor that list, applying patches that might be relevant to them. You keep the addenda for 2.6.X going until 2.6.X+2 is released.
This way there is no clear distinction between "stable" and "testing" kernels. There is, instead, gradual transition. People who want to be cautious can decide to use A testing kernel that has been out for at least 2 weeks - plus addenda as their definition of 'stable'. Others might prefer A testing kernel that has been out for at least 6 weeks - plus relevant addenda as their definition.
People who don't want to think, can pay a distributor to choose a suitable definition of 'stable'.
This way, you are giving your army of beta-testers clear information on their level of risk, and allowing them to choose precisely what level they want. Giving people information and choice is always good when you want them to help you.
That is the 'testing' side of the equation. The other side is the 'developing' side.
I have been (naively?) assuming that Andrew Morton is the 2.6 kernel maintainer, because that is what was announced, and I haven't seen any announcement to alter that. So I have been sending all my patches to Andrew to go in the -mm tree, with the understanding that he would forward them on to Linus as appropriate, and this has been working quite well. I feel free to send any patch to Andrew at any time, but try to make it clear which ones should be considered "work-in-progress", which should be considered 'important-bug-fix' and which sit in between.
I had (even more naively?) been assuming that this is what other developers were doing. i.e. that this was the approved approach.
But more recently I have discovered that quite a few key developers develop against Linus' kernel and submit patches directly to him, apparently bypassing Andrew. This leads to them holding back patches when a release is approaching, rather than sending them straight to Andrew for -mm and wider testing. This doesn't sound like a good thing.
Now, I know our movement is all about freedom (and openness), and you don't want to force developers into any behaviour patterns that aren't essential, but I think it would be nice if there was some uniform perspective on how patches should flow so that we all understood what each other were doing.
My own preference would be: - all patches go to Andrew and appear in -mm promptly - Linus only gets patches from -mm - most patches are only passed to Linus after they have been in an -mm release for at least .... 1 week (?) - some patches go straight to Linus even before a -mm release if maintainer + Andrew + Linus review and agree - some patches stay in -mm for extended periods getting refined before making their way to Linus. - some patches get ditched from -mm and never make it to Linus.
Is this too restrictive? Is it too much work for Andrew? Is it too little work for Linus :-?
Whatever the final answer, the key is to give all your volunteer supporters (both testers and developers) good information and good choices (and don't try to deceive them).
NeilBrown - 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/
| |