Broken master and newcomers.

Bjoern Michaelsen bjoern.michaelsen at
Wed Apr 6 07:21:32 UTC 2016


On Wed, Apr 06, 2016 at 08:04:39AM +0200, jan iversen wrote:
> I have been thinking for a while, if we could get jenkins to keep a marker of
> the last buildable version, store it somwhere easy to grap (preferable in the
> repo itself), and then extend our build instructions to do "git checkout" to
> that point.

That idea is old -- and yes, having it directly in as a note, tag or brach git
would be awesome. Personally, I would love to see a "master-ci-verfied" _branch_
that is following the master branch up to the point that is known good by CI. A
branch has the advantage that it would allow newcomers to locally rebase their
commit from one known good state to the next easily.

However, nothing like that has been implemted yet. So: go go go.

> An alternative (which I have seen used in another project), would be to let
> jenkins generate a source tar ball, incl. the .git directory, of the latest
> sane build.

No, thats horrible -- it make onboarding to git even harder.

> I know many will say, but master is sometimes broken, you have to live with
> that. That is a statement I agree with, for anything else than the first
> build.

Nah, the argument was rather: If we have a last 'known good master' everyone
will use that (including the people who broke master) and nobody will use the
HEAD of master anymore (nor will those that broke master).

My guess is that we need automating bisecting on master to really pin down the
guilty in these cases. See:;a=summary;a=summary

for some abandoned work I did for that. I gave up on it as with gerrit/Jenkins, master
state seemed 'good enough' to me.

> Any thought on how we can secure new contributors get a buildable version the
> first time ?

Heh, hanging those high that break master and didnt verify on Jenkins before --
esp. now that it is trivial?



More information about the LibreOffice mailing list