Lars Schneider <larsxschneider@xxxxxxxxx> writes: >> Also this would incur wait time on Junios side >> >> 1) collect patches (many series over the day) >> 2) push >> 3) wait >> 4) do the merges > He could do the merges as he does them today but after some time > he (and the contributor of a patch) would know if a certain patch > brakes pu. Read what you wrote again and realize that your step 1. does not require any expertise or taste from the person who does so. Anybody could do it, in other words. Instead of demanding me to do more of mindless chore, why don't you try doing that yourself with your fork at GitHub? I suspect you haven't read my response $gmane/291469 to your message yet, but "as he does them today" would mean _all_ of the following has to happen during phase 1) above: - Look at the patch and see if it is even remotely interesting; - See what maintenance track it should apply to by comparing its context and check availability of features post-image wants to use in the mantenance tracks; - Fork a topic and apply, and inspect the result with larger -U value (or log -p -W); - Run tests on the topic. - Try merging it to the eventual target track (e.g. 'maint-2.7'), 'master', 'next' and 'pu' (note that this is not "one of these", but "all of these"), and build the result (and optionally test). Then discard these trial merges. Two things you seem to be missing are: * I do not pick up patches from the list with the objective of queuing them in 'pu'. I instead look for and process topics that could go to 'next', or that I want to see in 'next' eventually with fixes. Queing leftover bits in 'pu' as "not ready for 'next'" is done only because I saw promises in them (and that determination requires time from me), and did not fail in earlier steps before they even gain a topic branch in my tree (otherwise I wouldn't be able to keep up with the traffic). * The last step, trial merges, is often a very good method to see potential problems and unintended interactions with other topics. A fix we would want to see in older maintenance tracks may depend on too new a feature we added recently, etc. Also see $gmane/291469 -- 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