Following on to this, I suggest that it should not be hard to configure a Windows machine with 16G of RAM, and set aside most of that memory as a RAM-drive. Then run the Windows build on the RAM-drive. That should speed things up. I do that here for some of my builds, and it makes a massive difference.
In fact, I could probably get permission to host such a machine here at work, provided that the build slave does not soak up too much network bandwidth (I'm in South Africa, bandwidth is expensive). Regards, Noel Grandin Noel Grandin wrote: > 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 >>
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
