Stefan Beller <sbel...@google.com> writes: > On Thu, Dec 10, 2015 at 3:51 PM, Junio C Hamano <gits...@pobox.com> wrote: >> Stefan Beller <sbel...@google.com> writes: >> >>>> * sb/submodule-parallel-fetch (2015-11-24) 17 commits >>>> ... >>> >>> I assume you plan on merging this after 2.7 settled and then we can >>> also get the above sb/submodule-parallel-update going again. >> >> Yeah, thanks for reminding me. I think that would be a good plan >> that gives us an opportunity to clean up this topic, some parts of >> which are have "an early patch that was too hastily merged to 'next' >> had to be tweaked by an 'oops' follow-up patch in the topic" >> pattern, e.g. "make waitpid the secondary and closed pipe the >> primary way to monitor children". >> >> Thanks. > > This makes it sound as if you would drop it from next once 2.7 is out, > expecting a complete reroll, which does the right thing from the beginning?
Yes, what is still in 'next' when a new release is made has the chance to (re)do the right thing from the beginning, and it also can lose merges from other topics in the middle of the topic if they have graduated to 'master'. A topic that did the right thing from this cycle already, but needs to stay in 'next' only because the area it touches is so important and deserves more real world testing by those who run 'next', may not have to reroll. I think two sb/submodule-parallel-* topics fall into the former category, i.e. ones that can take advantage of the chance to escape the rigidity of 'next' at the release cycle boundary, and I think we should grab that opportunity to clean these series up. Thanks. -- 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
