On Mon, Jun 04, 2012 at 08:02:43AM +0200, David Tardon 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_*) > * we already have tinderboxes for exactly that reason
A build breaker causes 10-20 times the ressources if it is found after hitting master compared to when it is found before that. Thats because 10-20 devs will: - have their build break - check how they broke it - find out they didnt break it - find the real breaker - try to fix it - find (or coordinate) with others who fix it too (two different fixes for the same issue are likely bad too) > Why not, if it is not mandatory... But I, for one, am not expecting any > spectacular results. I dont expect spectacular results. I expect a lot more visibility on what is going on in a particular area of code and better early "collision detection" between larger efforts. And it makes changes more transparent for newcomers. Around the Hackfest I heard multiple reports by casual volunteers that they can not follow the dev-list as it is too much traffic, too much noise. Gerrit might give you a more specific overview on what is happening in the area of your interest. > > about it (in which care it is sane to hold back until this is clarified) > > > - if you want to be faster, team up with someone for mutual review and you > > can > > be as fast as you want > > 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. Caolan is our top commiter. According to http://blogs.linux.ie/caolan/2012/05/20/8000-commits/ his last 1000 commits where at ~6 commits/day. Do you think it would take more than 10 minutes to skim over 6 commits, if they are presented in an easy accessable way? I dont think so. Best, Bjoern _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
