Date: Wed, 4 Sep 1996 11:46:40 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <199609041846.LAA07024@phaeton.artisoft.com> In-Reply-To: <3859.841858476@time.cdrom.com> from "Jordan K. Hubbard" at Sep 4, 96 10:34:36 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Adding latency is not the same thing as adding a "choke-point"; the only > > increasingly hypothetical thing here is the idea that a broken source > > tree is less of a barrier to progress than an increased latency for > > I was talking about a choke point for the developers, not the users. > Multiple make worlds running simultaneously don't work out very well, > last I checked, and it'd have to be something more like the public bus > system model than the private auto model we have now (you climb in and > drive whenever you like). Like I said before, I think centralizing it > would be a mistake and the real answer to simply fix the build process > so that it's less sensitive to anything outside its own build area. First of all, the users of the source tree *are* developers. Second, I would not disagree with the auto model if it were possible to grant everyone a license. This is technically infeasible, despite the fact it is the model OpenBSD claims to have adopted. OpenBSD will get to the point where the model fails at some point in the near future, and then they will have to restrict licenses to drive, or change their transpaortation model entirely. > > This will help in the external dependencies case, but it won't help in > > the "agregate changes fail to compile" case -- which seems to be the > > Why not? There are two ways in which you can easily generate a bogus > check build - bad source syncronization and external data pollution. > Fixing the tree doesn't avoid bad source sync, that's true, but it > does go a long way towards dealing with the second vulnerability. I > believe source sync is also manageable through reasonable use of CVSup > and CTM, though we still have yet to settle on the "trust" scheme used > to tell people when it's safe to go in the water. Because the feedback cycle which would enforce good practice by any other method than self-control is not there in the model. And humans are inherently incapable of exercising sufficient self control to cause the resulting construct to be stable in the long term. Otherwise humans would not have wars (among other problems relating to human nature). This is just another topological equivalent of the current model; it will work for 3-4 months, until the cost of personal inconvenience outweigh the cost of exerting self-control. Then *BOOM*, we are back discussing "why is the source tree broken" instead of "how is it that the process allows the source tree to become broken", or "how do we design a process that will drag it back to unbroken, like a satellite at L4 is dragged back into position". The saddle point of the effort of the resulting process needs to be centered at "unbroken tree". Rely on human nature, not human benevolence, to ensure hysterisis. Do it by codifying a process that promotes the desired result instead of a shortest-route process. The shortest route is not the lowest energy route; think of it in terms or obrital mechanics. If you want a permanent fix, then instead of trying to fix the results of the process, fix the process so it can't produce broken results. Then we never need to discuss the issue ever again, instead of 3-4 months down the road, the whole thing blowing up again. Check the -current list archives. I believe the problem is systemic, though I'm willing to be proven wrong by an examination of history. If there isn't a cyclic pattern to these discussions, I'm willing to simply shut up -- since I won't have to deal with the issue again: if it's not systemic, it won't repeat. Regards, 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?199609041846.LAA07024>