To be clear, I meant Jon_Y. Buildbot already does everything we need, and it takes one click to fire off an "official release".
The daily building is vital. It's a huge key to our success. What we need, and how people can help, is access to more windows slaves. All the ones we have left are mine, and there are hardware failures. I just brought up a backup cygwin slave. To the original question -- yes, we can get mingw builds building again. I am already scheduled to resurrect my mingw slave tomorrow afternoon. It was repurposed for a while because of non-mingw-related issues. On Fri, Mar 23, 2012 at 6:15 PM, NightStrike <[email protected]> wrote: > The below is an email that I 100% fully support. Thank you, Jon. > > On Thu, Mar 22, 2012 at 12:15 PM, JonY <[email protected]> wrote: >> On 3/23/2012 05:01, Jon wrote: >>>> Would it be possible to generate a new automated build for mingw? If >>>> I remember correctly the mingw build-bots were down? >>> >>> Perhaps it's time to rethink the current automated build strategy with an >>> eye on dramatic simplification. Something that's less onerous, less >>> complex, and more in line with the current project resourcing realities. >>> >>> Buildbot may be great for CI, but is it overkill for automated release >>> builds? >>> >>> How often are automated builds really needed? Once a week? Once a month? >>> Once a quarter? >>> >> >> Done everyday. >> >>> Are binary downloads for multiple platform types really necessary if great >>> build wiki documentation is available and maintained? >>> >>> IMO, it's time to focus on something foundational and sustainable. As a >>> strawman for discussion, I'm thinking of: >>> >>> 1) automated binary downloads once a month for only plain vanilla >>> i686-w64-mingw32 and x86_64-w64-mingw32 native builds. >>> 2) high-quality wiki documentation for building plain vanilla on Arch, >>> Ubuntu, FreeBSD, and OSX. >>> 3) no changes to the existing personal builds (actually, I'd like to see >>> Ruben copy Ozkan's excellent README summary available on the sezero SF >>> download pages) >>> 4) automated "official" build recipe based upon Ruben's >>> https://github.com/rubenvb/MinGW-w64-build-scripts The two official >>> automated builds (x86, x86_64) should be able to be built by _anyone_ using >>> (at a minimum) a recent Ubuntu system or Ubuntu running under a VM on >>> Windows. This isn't to say other platforms can't be used, but the baseline >>> is Ubuntu (Server?). Even though we all know Arch is the One True Distro, >>> it's probably too edgy for use as the baseline build platform. >>> >> >> 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. >> >>> FWIW, ~6 months ago I dug through Ruben's and was impressed with the >>> potential for using as the build recipes for semi-automated "official >>> builds." The two concerns I had then were (a) configuration setting, and >>> (b) automated repo source downloads/updates as part of the build process. >>> >>> By "configuration setting" I mean, easy declarative configuration setting >>> like: >>> >>> >>> https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L27-65 >>> >>> https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb#L40-73 >>> >> >> We really not like to add all the extras to the automated builds, last I >> heard, the build slaves network bandwidth is limited. >> >>> Of course it would use shell coding, not Ruby, but you get the point. >>> >>> I've recently cloned Ruben's github repo and had hoped to make time to >>> submit code specifics, but we all know how that story often unfolds. >> >> 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. >> >>> >>> This email is long enough, but I'd like to hear if you think the idea has >>> legs and what needs to be morphed. Specifically, what are the few specific >>> TODOs and who (other than the overworked project committers) are able to >>> take ownership of the tasks. >>> >>> Regardless, I feel strongly about four things: >>> >>> 1) This project needs regular, high-quality automated "vanilla" binary 32 >>> and 64bit mingw builds in addition to the personal builds. >>> 2) This project needs high-quality wiki build instructions for other >>> platforms. >>> 3) The bulk of setting up and maintaining any new automated build process >>> needs to _not_ fall primarily on Kai, Jon Y, or Nightstrike by default. Of >>> course they'll be involved, but the bulk of the work should be done by >>> interested contributors. >>> 4) Any new automated build process must be fairly easy to perform, and >>> generic enough to be easily transferred to a new maintainer. >>> >> >> In short, we need more build slaves machines to mitigate the effect of a >> downed machine, volunteers and donations are welcome. >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
