"Michael S. Tsirkin" <m...@redhat.com> writes: > On Tue, May 20, 2014 at 08:13:27AM -0700, Junio C Hamano wrote: >> "Michael S. Tsirkin" <m...@redhat.com> writes: >> >> > Just to clarify I can post v2 of 4/4 without reposting 1-3 since they >> > are queued? >> >> If you need to update anything queued only on 'pu' but not yet in >> 'next', it is customary to resend the whole for everybody to see >> (what is already in 'next' should only be built upon incrementally >> and not updated with replacement patches), while noting which ones >> are the same as before. Christian Couder has been doing it nicely >> in his recent rerolls (if the series were not in 'next', that is). >> >> Thanks. > > Actually I don't see anything like it in pu.
The way I usually work is to apply a non-fix (i.e. enhancement) series on a topic branch forked from 'master' (or the last tagged version contained in its tip) and see if it makes sense, and then try-merge the result to 'next' to see if it is free of potential funny interactions with other topics that are already in flight. After that happens, the topic branch is merged to somewhere in 'pu'. It is possible that I did not have time to go through all the steps above (after all, I had to make another -rc release and there was an unexpected last-minute change of plans in the morning that blew a few hours of work). Or there may have been some merge conflicts that I didn't feel like resolving for various reasons (e.g. if I knew the series would be rerolled anyway, it can wait; if the other topic that interacts with your series has been cooking sufficiently long in 'next' and if it is very close to the final release of this cycle, it may be easier to wait for the other topic to graduate to 'master', which would happen soon after this cycle finishes, and ask you to rebase your series). I don't remember which ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html