> On 16 Apr 2016, at 20:02, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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 Thanks for the explanation. My intention was not to be offensive. I was curious about your workflow and I was wondering if the Travis CI integration could be useful for you in any way. Best, Lars -- 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