2011/10/7 Marc-André Laverdière <marc-an...@atc.tcs.com>: > Wow, I really missed the 'big debate' :) [...] > - I agree that an email to 200 people is not super interesting. I think > we should run git bisect to try building for every commit until we hit > one that breaks, or build on each commit.
On linux and Mac we build fast enough that this is not a problem. the reason we get to 200 people, is that one commit break things, and 200 distinct people commit on top of that, there is no way for a tinderboxes to decided who to send emails to. you can't just send it to the original aithor because you can (and do) get the seuqnce A push commit 1 that break B push commit 2 that break A push fix to the commit 1 breakage In that case how do you make a tinderbox realize that it should send an email to B only ? > However, that is not so great > if we have commits for which the thing is fixed in the next commit. I > am not expecting everyone to be comfortable with git rebase to the point I am expecting them to be, that comes with the responsibility of being a committer, and I do think that keeping the history bisectable is a very good and important thing. > of merging commits all the time. But if we put such a policy in place, > it would help people learn very very fast :) > - Can we have some intermediary branch then? Or some 'proofed' branch? That is call 'your local directory' [snipped section essentially describing 'gerrit' workflow. we are working on that... ] > - I don't think we can expect developers to run a build before each > push, Yes we absolutely can expect that. it is actually a bare minimum !!!!! pushing to the main repo is not a game of 'throw mud at the wall and see what stick' > This would massively slow them down IMHO. Well that would massively speed up everybody else. > We have a relatively high rate > of commits. about 50 a day, and that is not 50 distinct push the tinderboxes do 20 to 30 iteration a day that is very close to an iteration per push. > It does happen from time to time that a commits comes in > just after you do your ./g pull -r ; make. So ? the issue is very rarely a conflict. the issue is new code not building. So if you successfully did a make before git pull -r, that cover 95%+ of the breakages > So you have to repeat the process, and that isn't so nice. Breaking master is not nice for the others.. because now they can really check that thei change are ok, sometime they can't even get to compile their change at all because to build can't even get there, so they have to bring locally master back to a 'older good point' (which require _them_ to 'repeat the proces' > Now, if I have to build something a gazillion times slower before I can > push, will I _ever_ be able to push? I'm not asking rhetorically by the way. Then don't push every 5 minutes. you only need make clean; make after a pull. so pull -r. make clean; make now you have a tree you can wok in. (provided master has not been broken... see how that brokenness is contagious ?) code, make, fix, make, fix, make.. commit, git status (to veryfy that you did not miss anything in the commit, if necessary:git commit --amend) Note that the 'make' above do not have to be global make... except for a last one when you ar ready to pull -r, you can make the module you changed (if it is a old-dmake module you need to build and deliver) Then pull -r if you have conflict resolve them and definitely make if you have no conflict, eyeball the change that got in and make a call about the likelihood of a 'silent' conflict. At that point, if you want to be very safe: make clean/autogen/make again... but if you don't an push, you still will be very unlikely to have broken master. Push ... AND keep an eye on the tinderboxes. usually within 20 minutes you should have the result of a tinderbox run with your pushed change in it (except windows so far). http://tinderbox.libreoffice.org/MASTER/status.html Norbert _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
