Hi Michael, On Mon, 23 May 2011 12:00:08 +0100 Michael Meeks <michael.me...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
