james.rich@m.cc.utah.edu said:
> Doesn't this seem a little like the problems occurring with lvm right
> now? A separate tree maintained with the maintainers not wanting
> others submitting patches that conflict with their particular tree?
> It seems that any project should be able to submit any patch against
> The One True Tree: Linus' tree.
Of course they can. Linus does apply them too. People are asking nicely
that ESR not do so in this case, because merges are being planned.
The contents of drivers/mtd/ are in the same situation. For some reason, I
felt it inappropriate to give every patch at every stage of development to
Linus for inclusion in the 2.4.0-test and 2.4.[123] kernels. Now I'm vaguely
happy with it all and it's stable, I'm working on cleaning up some of the
cosmetics and breaking it up into digestible patches.
Doing primary development in CVS seems to work OK for me, and allows me to
continue development without destabilising the One True Tree. During such
times, it's useful to have a branch for the code which is in the One True
Tree, so urgent fixes can be merged, and the diff against the One True Tree
after each release has something to diff against to catch patches where
people didn't even bother to Cc the maintainer.
I believe people were _told_ to hold off until 2.4.5-ish, or when the tree
became stable. Violent imagery was used to reinforce this instruction.
That being the case, how about holding the config changes back until after
everyone else who's been waiting has merged their pending changes?
-- dwmw2- 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/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:35 EST