On Thu, Feb 05, 2009 at 03:01:33PM +1100, Benjamin Herrenschmidt wrote: >Hoy ! > >So I've been annoyed for some time by the way we do our preparation for >the next merge window. The "next" branch is defined as not being rebased >ever (well, as much as possible), which makes it impossible to just >stash things early in there and rebase if needed, which is a useful >exercise in the weeks leading to the merge window to be able to test >patches, fix them, etc... while keeping a good idea of what's planned to >go in. > >Thus I've created a "test" branch. I'll push it out later today with >various things pending. For pulls from sub-maintainers, I'll probably >merge into "next" quickly (ie. a day or two after hitting "test" just >enough time to find gross problems). That will allow me to be more >pro-active also at pulling things off the mailing list and sticking them >there even if some cosmetic changes have been requested to the patch as >I will have no issue rebasing it when the new patch comes in.
I like this. So we have: test -> testing stuff next -> stuff that's been tested and is queued up for the next release merge -> fixes for the currently being worked on release Which begs the question of what master is for. So far, it's just been a mirror of next from what I can tell. Maybe it should just track Linus' tree? josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev