Date: Tue, 3 Sep 1996 11:08:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: michaelh@cet.co.jp, terry@lambert.org, kimc@w8hd.org, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <199609031808.LAA04620@phaeton.artisoft.com> In-Reply-To: <6665.841718171@time.cdrom.com> from "Jordan K. Hubbard" at Sep 2, 96 07:36:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Why do you need more than one build box? Is it because the snapshot from the tree is made on each download request instead of on a timed copy of the tree? I think a more reasonable, one machine, version would be: 1) wait some interval 2) copy active cvs tree to static cvs tree 3) test-build static cvs tree 4) if test-build fails, go to 1 5) copy successfully test-built static cvs tree to distribution cvs tree 6) people download distribution cvs tree Posits: a) the interval in step 1 should be as short as step 3 allows b) access to the distribution cvs tree should be blocked during step 5; this could be implemented with a simple access lock protocol obeyed by the copy process and the download process(es) c) we would prefer to block modification by programmers to the active cvs tree during step 2 to ensure an increased likelihood of buildability; a reader/writer lock would provide a guarantee here -- note, again: the guarantee is not necessary, only desirable d) assuming locing protocols, it's possible to split the process once per additional build machine, as a divisor into the interval in step 1: this could reduce the overall turnaround time between an active tree modification becoming available Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609031808.LAA04620>