On Wed, Feb 4, 2009 at 9:01 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > [...] > 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.
I'm cool with this. I certainly maintain a branch which is frequently rebased and that is exactly where I stash stuff as I try to decide what to do with it. The only difference is that mine isn't usually public. If people want to see it, then I push it out, but otherwise I just wait until I've got a real pull request. In fact, in this cycle I did push out to my -next and then had to redo it before I sent my pull request because one of the middle commits had an oops (but, nobody bases their patches on my -next tree, so it doesn't have the same repercussions). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
