On Mon, Nov 14, 2016 at 05:35:56PM +0100, Torsten Bögershausen wrote: > > What is the goal for 'pu'? > > > (1) Builds clean on all platforms + passes all tests > Yes > > (2) Builds clean on all platforms > Yes > > (3) Builds clean on Linux > Yes > > (4) Just makes new topics easily available to a broader audience > Yes I'd have answered differently, though I think in the end we agree on the outcome. I think the only thing that matters is (4). It _usually_ builds and passes all tests, but not always. But the point is that nobody should care in particular about "pu". What we care about is whether the individual topics will build and pass before they are merged to master (or even "next"). So "pu" is a tool, because you can test all of the topics at once and find out early if there are any problems. And it's good to investigate problems there before topics hit next (though they are also often caught in review, or by people trying the broken topic on their various platforms, or sometimes Junio even pushes out a known-broken state in pu and mentions it in "What's cooking"). So yes, it should do all of those things, but we don't necessarily expect that it will never be broken. That's expected to happen from time to time, and the purpose of the branch. With respect to Lars' original point: > > Git 'pu' does not compile on macOS right now: > > builtin/bisect--helper.c:299:6: error: variable 'good_syn' is used uninitialized > > whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] The next step is to make sure that the topic author is aware (in this case, one assumes it's pb/bisect). Better still is to make a patch that can either be applied on top, or squashed as appropriate. I know that Ramsay Jones does this, for example, with some of his sparse-related checks, and I'm pretty sure from the turnaround-time that he runs it against "pu". -Peff