Paolo Bonzini <bonzini@xxxxxxx> writes: > Is your workflow to merge next to master after the release, or do you > cherry-pick the merges? Usually 'next' will never rewind, and topics graduate by merging into 'master', either as a whole or in steps. But I've kept 'next' and 'pu' deliberately more inclusive during this -rc period, knowing that people by now would be very well aware that after the final release of 1.6.4, 'next' will be discarded and rebuilt with a few selected topics. That means what currently is in 'next' can be safely kicked back to 'pu' or discarded if it turns out to be necessary. If you have doubts or regrets in the series currently in 'next', you can even send in replacements if you want to (which is not how 'next' works normally). I can revert the merge of the original series to 'next' and merge the replacements during -rc period. After 1.6.4, I can discard the original series and keep only the updated series. On the other hand, if you want to keep going incremental, which is how 'next' is supposed to work, that is perfectly Ok, too. After 1.6.4, we can decide what to do. > Do you plan to merge at least the first two patches of "git push > --current" (i.e. without the config option)? I am not quite sure if that is a good approach. If the design is in flux, perhaps we should cook the code in 'pu' a bit longer until we know what end user interface want? The last thing I want to do is to give end users a set of new command line options in 'master' (or even 'next'), only to revoke them before the next release. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html