Date: Mon, 03 Jun 2002 23:23:04 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Will Andrews <will@csociety.org> Cc: Kris Kennaway <kris@obsecurity.org>, arch@FreeBSD.ORG Subject: Avoiding unnecessary breakage (was Re: Removing wait union) Message-ID: <3CFC5CC8.22AE7B92@mindspring.com> References: <20020602010108.B16166@espresso.q9media.com> <20020603011903.Y2566-100000@gamplex.bde.org> <20020603162508.A34224@xor.obsecurity.org> <3CFC00A9.BD98B7BD@mindspring.com> <20020603181537.A37707@xor.obsecurity.org> <3CFC1905.BF824FF3@mindspring.com> <20020604034246.GD53809@squall.waterspout.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Will Andrews wrote: [ ... ] This thread is not about the ports cluster, per se. We could actually care less about actually building the ports as they will be used, in this case. It is a proposed means, not an ends. I have changed the subject to avoid any further confusion. -- This whole thread started because Kris wanted developers to be individually responsible for fixing the ports that broke because of their commits to the OS, or, as a minimum second derivative, for notifying the official maintainer of a port that was broken as a result of such a commit. This requires that developers making such changes have a-priori knowledge of the effects of their changes on code that is probably not, nor ever will be, installed on their machines. The problem with just requiring this unilaterally is that I don't know of one developer, other than Kris, who has a box with all of the ports source code on it so that changes that might have this impact can be tested. Why am I posting at all in this thread? I'm personally philosophically opposed to the idea of "bit rot": when the ISODE and X.25 code "rotted" because it was not maintained when the routing code was changed out from under it, and when the LFS code was moved to the attic because the unified VM/buffer cache code changes were checked in without maintaining the LFS code (a client of the VM and buffer cache code), it really pissed me off. It really, really, really pissed me off. Kris has identified an analogous situation with base system changes impacting ports. It's a natural extension of the same philosophy, though it's harder to justify unilaterally, because it involved third party code that's not "part of the OS". My participation in this thread is therefore about whether or not it's possible to come up with some method of determining what ports will be broken by a proposed change, before that change is made, and in a reasonable time frame, with a reasonable amount of effort, which it would be reasonable to expect a developer who is contemplating such a change to expend. In effect, this means that, if this idea is to go forward, there are only a few obvious courses of action: 1) Build another "ports cluster" so that changes can be tested before they are committed 2) Find another way around the problem, which has less overhead than #1 3) Run all such changes through the existing ports cluster by having Kris apply them locally on the machines, without them having been checked into CVS, and giving a thumbs up/down to the change. 4) Tell Kris "lump it": breakage is going to happen, and it's up to you as the ports guy to mop out the rest rooms after the concert, after we have peed all over the fixtures (i.e. leave things as they are now). Call me crazy, but I think #4 is not an option. Kris would not have raised the issue if it were OK with him to define the breakage as "necessary". I also don't think that #3 is an option. The anti-process people would probably object to having to run their code through another volunteer, who could not say "yes/no" until he could find the time. It would, at the very least, be a definite bottleneck. #1's a possibility, but it's unlikely to be a useful possibility, and it almost implies #3, since it requires a gatekeeper, if only for scheduling use of the cluster. Such resources would probably be better spent on doing the primary work of the ports cluster, anyway: building ports. So that leaves #2. If you can think of any other options, please chime in *now*. So if you don't mind, I'd like to continue looking at ways to attack implementing #2, unless you are prepared to find someone else (or ar volunteering yourself, instead of implicitly volunteering Kris, again) to muck out the restrooms after the next concert. Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFC5CC8.22AE7B92>