On 3/23/2012 09:23, Jon wrote: >>> How often are automated builds really needed? Once a week? Once a month? >>> Once a quarter? >>> >> >> Done everyday. > > Sorry, I overloaded "automated builds"...should be "How often are regular > project release builds really needed?" I think most users would be more than > happy with a monthly mingw-w64 release schedule. > > > >> No need for recipes or what not, there is already an existing puss >> button buildsystem. All that is needed is a VM with good uptimes. > > I disagree. While the push-button buildbot build system may work well for the > internally useful automated builds, it doesn't appear to be working well as a > regular mingw-w64 project release build system. > > Maybe it can be fixed with a VM with good uptimes, but I doubt it. You guys > are smart and if it was this as easy as this, you'd have fixed it awhile ago > and we would be having this discussion. > > Something else is the roadblock. > > My view is that buildbot process is too heavyweight (as a regular release > build tool) for the realities of the current mingw-w64 resources. > > I'm not against CI, but I think something more lightweight, something more > attractive enough to potential new maintainers, and something easily > replicated/setup for only official project release builds is the solution. > And buildbot doesn't go away, it just gets used internally by you and the > other committers for fast regression testing. > >
It's down most of the time because the buildbots are leased on a volunteer basis without any regard to support capability. We also do not have any physical access to them, which limits us to sending ping emails to the machine owner to recover it. IMHO, we simply need a canned VM appliance that we can push to our volunteers, that way, we can quickly replicate our build slaves. As new maintainers come in, we just tell them to stick the appliance into their VM while we register the new slave. > >> As for buildsystem configuration testing, please look into >> makebuildroot.mk and makebuildroot-test.mk in /experimental/buildsystem. >> >> The former is followed closely by buildbot. The latter does all the >> whizzbang like winpthreads, libgomp etc. All the config is near the top. >> The 2 makefiles diverged a bit after some time, with the latter aimed >> for the user who wants this-and-that included in his build. > > Fair point, and I'll look again. But even if this is updated to generate > usable project release builds, it still seems too heavyweight and you still > have all the maintenance issues that exist today. The need for more > contributors who want to deal with buildbot vagarities, the need for build > machines, etc. > > Both Makefiles are usable by the user, assuming the user has all the prerequisite host programs already installed, it'll pull all the gcc deps and build it from source. > >> In short, we need more build slaves machines to mitigate the effect of a >> downed machine, volunteers and donations are welcome. > > Pragmatically, I strongly believe a lightweight shell script repo like > Ruben's is the way to go for the mingw-w64 project. Easy to clone onto a > machine/VM, easy to understand, easy to maintain, and easy to take over > maintenance when the previous maintainer wants to move on. > Its not much different from the Makefiles (it was developed from a shell script that got unwieldy due to the language inflexibility). Builds with a single make command, can continue on even if interrupted half way through. As for scripting, I'm biased towards using the far more flexible Perl language over shell script, but I'm sure they'll be quite a few objections about readability. Besides, no need to code up something new when the existing version works fine.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
