Date: Tue, 04 Jun 2002 16:09:16 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bakul Shah <bakul@bitblocks.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: <3CFD489C.D45F2ADE@mindspring.com> References: <200206041752.NAA08182@rodney.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah wrote:
> Another possibility is to figure out a way to not cause so
> much bit rot in the first place. Let me explain.
[ ... ]
> So there is usually a group (or an individual) commited
> maintaining compatibility. Breaking interfaces is not prohibited
> but it is not taken lightly.
[ ... ]
I think that I can safely characterize this as my "option #3",
where the changes are vetted by "vetting committee"/Kris/software.
I think this instantaneously creates a bottleneck. The emergent
properties of this bottleneck are undesirable, even if the intent,
to avoid breakage, is desirable.
> 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).
I think Kris would probably agree with this. 8-). I do.
> 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.
I'd agree with an architecture group, but I think the powers
you want to grant are perhaps to far-reaching.
Already, the mere existance of a tiered structure of core team,
committers, the unwashed masses, is externally seen as being
non-egalitarian in the extreme. There are also some intrinsic
properties of such a system. The political analogs are super
powers, the members of the "nuclear club", the unwashed masses;
the economic analogy is first world nations (the G-8), second
world nations, and the unwashed masses. The business version
is executives. middle manage, the unwashed masses.
The overriding intrisic property is that such systems are tier
exclusionary, and they are self-perpetuating.
Adding another tier of management is probably not the answer
("Welcome to the Star Chamber").
> 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!
Actually, that was me that already mentioned this one; it was
in the context of the "making BSD make into GNU make" thread.
This is antithetical to the use of "automake/autoconf/configure"
used by many ports. It's much closer to the "imake/xmkmf" way
of abstracting system differences as a list of manifest constants.
It's not that this approach won't work, it's that responsibility
for compliance is pushed off onto the third party code maintainers;
you are effectively telling them not to use certain tools that work
perfectly fine for them on their single OS environment, and which
help in making ports of their code -- at the expense of making the
code itself less portable.
-- 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?3CFD489C.D45F2ADE>