Hi Christian, On Sat, 22 Apr 2017, Christian Couder wrote:
> On Sat, Apr 22, 2017 at 1:48 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > >> > >> First bisect should ask you to test merge bases only if there are > >> "good" commits that are not ancestors of the "bad" commit. > > > > Please note that this is a stateless job. The only "state" I have is > > the branch name. > > > > So when something goes wrong, I have *no* indicator what is a known > > good state. > > Maybe we could consider the last release a known good state? You mean the latest release. I would expect that we won't have a last release in a long time... Using the latest release as a 'known good' would not improve on using the strategy I chose, as the latest release is at most up-to-date with maint/master. In the case of `pu`, for example, it is much better to test `next` and use it as a known good state if it passes. If we had a Pull Request centric workflow with one integration branch (as opposed to four), it would be relatively easy, as `master` would always be expected to serve as a "known good" state, and it would be the policy that the build has to pass before Pull Requests would be accepted. But we don't, and that's that. Ciao, Johannes
