Date: Tue, 3 Sep 1996 20:09:01 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: current@freebsd.org Subject: Re: Food for thought Message-ID: <v02140b10ae527e78dfb3@[208.2.87.4]>
next in thread | raw e-mail | index | archive | help
>Richard Wackerbarth stands accused of saying: >> >> >Richard Wackerbarth stands accused of saying: >> >> >> >> 1) Although I like the idea that "current" is readily available, forcing >> >> new development to be done against it leads, IMHO, to making people use >> >> something which is more unstable than what they need or desire. The >> >> tradeoff is in the integration. >> > >> >Bollocks. -current is _incredibly_ stable for what is a running >> >second-by-second snapshot of a development tree in full swing. >> >> But many would be contributors have absolutely no need for such >> second-by-second access. They need a reasonably current platform against >> which they can do useful work. > >Which is what the -SNAP releases are for. Are you just being intentionally >dim or something? I thought at the start that you actually had some sort >of vaguely coherent idea of what you thought was the Right Way. So far >all you've done is whine about problems that don't actually exist. I disagree about the adequacy of "snap" releases. Jordan seems to get them out perhaps once a month. (I'm not faulting him) There are those who want to help check out things with much less latency, like maybe a day. The only problem is that they don't want to spend all of their time just getting the build to work. I think that Jordan is on the right track with his idea of an automated build "certification" scheme. If we implement such a scheme, it will soon become obvious whether the users are simply "whiners" or that they honestly have a beef. I propose that we divorce "current" from "head" in the sense that "current" becomes controlled snapshots of "head". Anyone who wants "head" MUST get it by cvs. To start, "current" would be "released" the 4 times per day that correspond to the ctm distribution of cvs. At each "release", a ctm-cur update would be generated. This would be the distribution method of choice for those who keep the entire tree and track it closely. (That includes, especially, the -current sup servers which would update in response to the release) As we find some willing machines, we can introduce a "certification" phase whereby the distribution is checked out and compiled. If it passes, notification is sent to release (or encourage the release) of a particular level of "current". Since the ctm-cur generator is the arbitrator of releases of "current", the policy would be implemented there. However, it would not be difficult to allow the reports to be generally distributed so that anyone with a cvs tree could make their own decision.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b10ae527e78dfb3>