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: > 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 > Disclaimer: http://www.peralex.com/disclaimer.html
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
