Date: Wed, 4 Sep 1996 21:18:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <199609050418.VAA08185@phaeton.artisoft.com> In-Reply-To: <199609050321.UAA02205@root.com> from "David Greenman" at Sep 4, 96 08:21:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >improvements. Whether you like it or no, we have to "sell" FreeBSD. Making > >not only the code, but the organization, more user friendly will influence > >far more people than will the excellent quality of the internals which you > >already do well. [ ... ] > >I have a different perspective. There IS a problem. Jordan, Terry, Nate, > >and I, and perhaps others, have discussed a possible solution. I offered to > >be the coordinator of the effort to move to something that will address the > >problem. > >I have even given a detailed description of the new scheme. > > I think you're looking at the problem with blinders on. Whether the sources > build or not is a _very_ small problem when compared with the larger issue of > whether or not the code works correctly. As I've already said, it's our policy > that the code should compile after a CVS commit. If it doesn't then this is > clearly a mistake and perhaps people should try harder to at least satisfy > this requirement. > > What you should be complaining about is not source tree build problems. The > real problems are with the proper operation of the code. This is a far bigger > problem - certainly more critical to the success of FreeBSD - and one that > doesn't have any easy solutions other than rigorous testing (which we do of > course, but can take weeks of time to show up certain problems). ...and we > have addressed this problem in the only way we reasonably can: it's why we do > releases. Look at it logically: 1) Inre: testing Posit: The ability to reliably compile current will increase the use of current Posit: Increased use implies increased testing Conclusion: It is possible to increase testing by increasing the the ability to reliably compile current 2) Inre: load on the core team Posit: Most "fires" posted about on the -current list are the result of failure of the tree to build as expected, for whatever reason Posit: The main reasons the tree fails to build as expected are "pilot error", "internal tree inconsistency", and "race conditions in the process of making the tree available" Posit: Most "fires" posted about on the -current list must be verified/refuted by an expenditure of effort, generally by a core team member Posit: The verification/refutation of a given "fire" constitutes "load" Conclusion: It is possible to reduce load on the core team by removing the possibility for "pilot error" in the build process, removing the possibility for "internal tree inconsistency" (either in the real tree, or in the exposed tree), and by closing the potential race windows. Pretty obviously, the only negative effect is "status quo is changed". I claim that the measurement system that calls this a negative effect is, itself, flawed. 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?199609050418.VAA08185>