Date: Tue, 04 Jun 2002 10:52:56 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Will Andrews <will@csociety.org>, Kris Kennaway <kris@obsecurity.org>, arch@FreeBSD.ORG Subject: Re: Avoiding unnecessary breakage (was Re: Removing wait union) Message-ID: <200206041752.NAA08182@rodney.cnchost.com> In-Reply-To: Your message of "Mon, 03 Jun 2002 23:23:04 PDT." <3CFC5CC8.22AE7B92@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm personally philosophically opposed to the idea of "bit rot": Me too. > 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). Another possibility is to figure out a way to not cause so much bit rot in the first place. Let me explain. Most systems companies understand the software they sell (and around which their customers and 3rd party vendors add much more software) exists to solve customers' problems and breaking interfaces DOES NOT help that cause. So there is usually a group (or an individual) commited maintaining compatibility. Breaking interfaces is not prohibited but it is not taken lightly. Alternatives are explored to eliminate or at least, reduce the pain a customer or 3rd party vendor has to go through to upgrade. This is also why a lot of care goes in documentation -- what is not promised doesn't have to be maintained. Such an entity seems to be missing in the FreeBSD camp (and others too but we are only talking about FreeBSD here). Leaving such decisions solely upto developers doesn't work because developers have their own agenda (which is frequently at cross purposes with each others', and with the groups' goals). In my view having an active architecture group that is responsibile for user/system interfaces would help tremendously. In order for it to be effective it needs people who have developers' respect for their judgement, experience and technical skills. They need to be persuasive and tough enough to help convince developers to work toward a common goal. Whether this is doable in the FreeBSD world, I can't say. I don't see most FreeBSD developers accepting such a change easily even if you can find people with skills, sound judgement and free time; but with over 7000 ports there needs to be policy changes as well, not just mechanism changes (which is what your #1, 2 & 3 are about). Another mechanism idea to add to your list (I think someone may have already mentioned it): - create an index of which ports use what include files, what system/library calls etc. If an interface needs to be changed the developer can quickly find out what ports will be affected. If the developer were forced to fix these ports before allowed to commit an interface change, most people will think harder about changes! Comments? -- bakul 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?200206041752.NAA08182>