On Mon, Jun 4, 2012 at 1:02 AM, David Tardon <dtar...@redhat.com> wrote: > On Sat, Jun 02, 2012 at 10:51:25AM +0200, Bjoern Michaelsen wrote: >> So -- people with commit rights are not the issue: >> - can commit directly to master on their own responsibility >> (this should be discouraged, except for urgent buildbreaker fixes that save >> everyone pain) > > Do I see the beginning of some "CWS" process here? Anyway, if the > objective is to avoid build problems, then I think it is completely > misplaced, because: > > * no amount of reviewing is going to cover all the configurations people > build with > * most of build problems are on Windows and MacOS X and we do not have > enough people there (c.f. the recent threads regarding testing of > feature/gbuild_*)
The idea is to test build _before_ landing on master The advantage of gerrit is that a tibderbox can test individual patches in an automated fashion and without the need for speed that the current tinderboxes have. Right now it is very important to have fast tinderboxes to turn things around fast enough to that borkage do not stock pile (as it used to be with windows) But with gerrit the build-testing scales up nicely as the time to test build a given patch is not critical anymore... so we can make productive use of any kind of box big and small. Sure at first we won't have enough of them to really test every patches on every platforms... but it is a reachable goal. Furthermore this kind of setup would allow for tests to be run, even slow ones, since again the time to process a given patch is less critical than with today's setup. So there won't be the need for a tug of war between speed and completeness. Of course all of that will not materialize magically just because we tart using gerrit, but it is a step toward the _possibility_ of such infrastructure > > I do not think it is a good idea to start to do that for master commits > wholesale. We have hardly enough people to review fixes for stable > branches. a/ gerrit make it easier to do such review b/ the habit of doing review is indeed not the easiest thing in the world to instill in a project (open source or not), but it is a worthy goal. c/ the burden and responsibility of a review for master is much less than that of a review for stable branch. This goes back to the discussion of 'lock sane' vs 'I know it is working, I'll stake my name on it' Norbert _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
