Wow, I really missed the 'big debate' :) Anyways, here are some things that went on my mind going through the list:
- IIRC, some projects have build farms available... why is it we're not using theirs to supplement ours? I see here that GCC is willing to help any free software project: http://gcc.gnu.org/wiki/CompileFarm - Can we have distributed builds in non-Linux systems? If so, I think it wouldn't be so hard to make the tinderboxes help each other in building things - 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. 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 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? If we build after each commit, the CI service can push that commit that is OK to the 'proofed' branch, and then only those commits would be tested with others. A failed commit would mean an email to the author and/or commiter. Only after the commit is fixed will it reach 'proofed'. And we could build nightly from 'proofed'. - I don't think we can expect developers to run a build before each push, especially not with all the debug options enabled and the like. This would massively slow them down IMHO. We have a relatively high rate of commits. It does happen from time to time that a commits comes in just after you do your ./g pull -r ; make. So you have to repeat the process, and that isn't so nice. 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. Just my 2 paise :) Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 10/07/2011 09:30 AM, Kevin Hunter wrote: > At 6:28am -0400 Thu, 06 Oct 2011, Norbert Thiebaud wrote: >> 2011/10/6 Norbert Thiebaud: >>> I'll give it a shot... >> >> Not that I expect it to make a big difference... since most of the >> compiles are ccached... > > As an nth data point on the matter, I've been using ccache for awhile, > and my builds take longer. Anecdotally (because I'm not focused on > ccache specifically), I turned it off the other day, and my builds > reduced from about 2 hours to 1h15m.* For reference, my ccache size is > 8G, but only 1.8 G has been used. My hits at about 12,000 are about > half of my misses. > > Cheers, > > Kevin > > * Both of those numbers are _very_ rough averages (created from memory > of my "alias make='time make'" output), my builds compile in the > background, at nice +19, on a puny dual-core 4G machine with a latent > rotating HDD. The majority of my builds are "./g pull -r; make" used > for testing. The less rough average is the "make distclean; ./g pull > -r; make" workflow, which reduced a 3h30m compile to about 2h05m on the > same hardware. > _______________________________________________ > 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
