Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 24, 2017, 14:08 UTC
Message-ID: <alpine.DEB.2.20.1704241604030.3480@virtualbox>
In-Reply-To: <CAP8UFD3QJ5irxNZqn__CqXPgi+uY4vhZ2HyrNu9RhScbRU0LOA@mail.gmail.com>

Hi Christian,

On Sat, 22 Apr 2017, Christian Couder wrote:

Show 13 quoted lines

> On Sat, Apr 22, 2017 at 1:48 PM, Johannes Schindelin
> <Johannes.Schindelin@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