Date: Mon, 02 Sep 1996 19:36:11 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Michael Hancock <michaelh@cet.co.jp> Cc: Terry Lambert <terry@lambert.org>, Kim Culhan <kimc@w8hd.org>, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <6665.841718171@time.cdrom.com> In-Reply-To: Your message of "Tue, 03 Sep 1996 09:31:13 %2B0900." <Pine.SV4.3.93.960903085814.28456B-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> I haven't seen any real solutions to the buildable-current problem. Actually, I've been proposing a solution for close to 2 years now, we've just never actually set about the process of implementing it. 1. What is currently thought of as -current right now goes into "slow update mode", the tree no longer being updated automatically via cron, as it is now. 2. Those -current users who are really developers and don't mind temporary brokenness (they perhaps even being occasionally responsible for same) either CVSup the CVS tree or the `.' tag from it. Grabbing the `.' (or HEAD) tag with CVSup is also therefore no longer considered as synonymous with "supping -current" 3. The "slow update" of the -current tree on freefall, from which the sup and CTM services are provided, is driven by a "cookie collector" process - some PERL script hanging off an email alias which collects success-or-fail messages from a set of designated build boxes. Each designated build box, some of which we could provide here at WC, commits to updating to and building the CVS HEAD branch once every 24 hours, emitting an email at the end to know the central cookie collector know the exit status of the build. If a majority of the build boxes report success during a given 24 hour period, and I'd recommend making it a majority vote since a given percentage will *always* be hosed due to local stupidity of some sort, then the for-public-consumption tree will be updated. That would solve the problem nicely, but so far none of the "current is broken *again*!" complainers have been willing to sit down and actually implement the framework necessary for making this work. Jordan P.S. A human-driven model for this will *NOT* work. Such a buildmeister person will simply burn out on the process in short order, needlessly wasting everyone's time and one buildmeister.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6665.841718171>