[Libreoffice] master & patch review process ...

[Bjoern Michaelsen]

Hi Michael,

On Mon, 23 May 2011 12:00:08 +0100
Michael Meeks <michael.meeks at novell.com>
wrote:
> 	Also, my experience of building master is that it is not
> -that- bad: by -that- bad, I mean the pre-CWS nightmare of Hamburg
> times (as an example). Of the dozen times I've pulled and updated
> recently - my build has failed perhaps 5 times, of which 3+ have been
> simple incremental build failures (fixed by gnumake), and another ~2
> perhaps real issues, one of which has been fixed by the next './g
> pull' and ... is there really a problem here ?
Every sixth build breaking (ignoring the incrementals) is not welcoming
to newcomers, because they cannot get started. And it is more than
every sixth build having serious trouble, master was broken over more
than the complete last weekend -- while it did build, but did not start
or smoketest.

> really fix the underlying problem: which is one of not having enough
> skilled (and brave) reviewers who can wander outside their area of
> expertise, and work hard to get things included.
Reviewers have absolutely nothing to do with this, as stuff goes to
master unreviewed. And unfortunately it goes also in untested -- that
is: not even tested on _one_ platform. For not testing on other
platforms, we cannot really blame people as there is little possibility
for them: If you want a tinderbox to build your stuff you have to push
it to master and hope for the best. (Can we change that?)

For testing on your own platform we are equally guilty: When master
does not build or survive basic testing (as it does often), there is no
way to test your changes. This is also a moral hazard as demotivates
people from testing: After experiencing a "Ah, it was broken before
anyway" two times, they might not bother anymore. Anything commited on a
broken master is untested by definition unless it explicitly fixes the
issue.

As for the "experienced hackers" hunting down the breakers: True,
that is possible, but a terrible waste of resources. Indecently, you
are rightfully complaining about the lack of resources. As is, we have
no coordination on who heals master, when it breaks: Either nobody
does -- leading to frustration everywhere, or multiple people do --
thereby wasting resources.

This is why we should prevent this from even happening as much as
possible. Honestly, as I saw master being basically broken again by a
somewhat larger push, I was tempted to revert the whole bunch to the
last known good state. The issue was trivial to fix in the end, but the
funny thing about a breaker after a larger push is: it is not easy to
tell that beforehand.

The cheapest fix is not letting stuff break on master. The second
cheapest fix is letting the guy fix it who broke it ASAP. The most
expansive way to fix master is to let the most experienced hackers hunt
the issue in larger sets of commits, while everyone else is standing on
the sidelines and is getting frustrated.

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen