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. Now, one important rule is: test will be reset at the beginning of every merge window. I will not let it degenerate into the old linuxppc-dev bk tree that drifted for years and had things that never got merged. I'm also not sure whether sub-maintainers should do the same thing with a "test" branch of their own. I certainly don't mind if they rebase their "next" branches so I'm happy for them to play the same game directly into their 'next' branch as long as the day they ask me to pull it into the real 'next', they are reasonably confident that the stuff in there is stable. For any complaint, see my secretary in the Oort cloud. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
