On 3/24/2012 06:09, Jon wrote: >>> 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. > > Ah, that is very unfortunate. > > >> 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. > > A canned VM is a great idea. I think untethering it from the buildbot for > regular release builds will turn out more maintainable in the long term. I'd > like a canned appliance in which one simply clones an updated Ruben repo and > builds. Forget buildbot masters, slaves, configuration, and registration. > Control access by giving only the current release manager the ability to > upload to SF. Not fully automated, but highly automated. >
Or just use GnuPG PKI, the uploads are signed, only if it can be verified by a known list of slave public key, then it'll be moved from the staging area to the public downloads. Or we could integrate it sftp login controls. This should automate things a bit. > That said, short term, I wonder if a similar idea could help to quickly get > the mingw binary builds up and working while we discuss longer term ideas. > > Specifically, configure local buildbot networks on a single computer using a > network of VMs. For example, I have a Win7 32bit notebook with 4GB on which > I simultaneously run both an Arch VM and an Ubuntu Server VM using > VirtualBox. Each VM has eth0 NAT'd to the Win7 host (with SSH port > forwarding) and eth1 on a private 192.168.*.* local network. The VMs > communicate on the local network via SSH, etc. > > Can we sidestep the current physical buildbot problem by running a buildbot > master in one VM and a slave in another VM all on one machine and start > generating regular 32bit and 64bit mingw builds again? > > As you can imagine, I think this is a horribly complex "fix", but it could be > interesting short term. > > Also, it will be interesting to see what Vincent Torri might be able to do > wrt additional build resources. > Perhaps, but I'm not sure its feasible to make the masters are decentralized, we loose the ability to query individual slave status. P.S. You really need to turn on word wrapping in your emails.
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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
