<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> It seems like Windows builds in particular would benefit from either (a) tons and tons of RAM or (b) an SSD. Who owns the hardware? Perhaps I (or the company I work for) can contribute to the cost of (a) or (b). Regards, Noel Grandin Norbert Thiebaud wrote: <blockquote cite="mid:CAFWMYEE1_qTyxF4ennp1sxy913cNNQD-QQksWmLvSJ=NttTqTA@mail.gmail.com" type="cite"> <pre wrap="">2011/10/7 Marc-André Laverdière <a class="moz-txt-link-rfc2396E" href="mailto:marc-andre@atc.tcs.com"><marc-andre@atc.tcs.com></a>: </pre> <blockquote type="cite"> <pre wrap="">Wow, I really missed the 'big debate' :) </pre> </blockquote> <pre wrap="">[...] </pre> <blockquote type="cite"> <pre wrap="">- 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. </pre> </blockquote> <pre wrap=""> 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 ? </pre> <blockquote type="cite"> <pre wrap="">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 </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap=""> That is call 'your local directory' [snipped section essentially describing 'gerrit' workflow. we are working on that... ] </pre> <blockquote type="cite"> <pre wrap="">- I don't think we can expect developers to run a build before each push, </pre> </blockquote> <pre wrap=""> 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' </pre> <blockquote type="cite"> <pre wrap="">This would massively slow them down IMHO. </pre> </blockquote> <pre wrap=""> Well that would massively speed up everybody else. </pre> <blockquote type="cite"> <pre wrap="">We have a relatively high rate of commits. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">It does happen from time to time that a commits comes in just after you do your ./g pull -r ; make. </pre> </blockquote> <pre wrap=""> 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 </pre> <blockquote type="cite"> <pre wrap="">So you have to repeat the process, and that isn't so nice. </pre> </blockquote> <pre wrap=""> 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' </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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). <a class="moz-txt-link-freetext" href="http://tinderbox.libreoffice.org/MASTER/status.html">http://tinderbox.libreoffice.org/MASTER/status.html</a> Norbert _______________________________________________ LibreOffice mailing list <a class="moz-txt-link-abbreviated" href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/libreoffice">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </pre> </blockquote> <hr>Disclaimer: <a href="http://www.peralex.com/disclaimer.html">http://www.peralex.com/disclaimer.html</a> </body> </html>