Date: Tue, 04 Jun 2002 17:51:14 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Garance A Drosihn <drosih@rpi.edu>, Terry Lambert <tlambert2@mindspring.com>, Brian Somers <brian@Awfulhak.org>, Poul-Henning Kamp <phk@critter.freebsd.dk> 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: <200206050051.UAA07971@renown.cnchost.com> In-Reply-To: Your message of "Tue, 04 Jun 2002 14:34:34 EDT." <p05111724b922b2b4d44b@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
[Executive summary at the end]
> >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. ...
>
> Most system companies who SELL software are also PAYING their
> employees to work on that software.
Yes, paying makes it relatively easy to make people work
toward a common goal. In a volunteer organization this is
much harder but not impossible. You do need a leader (or
leaders) to articulate the common theme and you also need
someone to help people move toward a common goal.
> Note that some of the changes we are talking about are being
> done to conform to standards. It isn't just "random bit rot",
I am *not* suggesting people are making changes for the sake
of changes. What I am suggesting is that the common theme of
"making the customers' life easy" is either missing or there
is no agreement about just who the customer is. So what is
"right" at a micro level can some time end up creating more
pain at a macro level. What is "right" technically can also
end up being a royal pain to fix.
I am ambivalent about "standards". If conforming to a
published standard breaks a lot of things, I'd say that is a
bad standard and I wouldn't go out of my way to meet it.
> I hope this is not sounding too sarcastic, because I do agree
> with the general idea that we should "avoid unnecessary breakage".
> It is pretty easy to say that, but it is hard to actually do it,
> while still moving the operating system forward.
No disagreement here.
Brian Somers writes:
> Many software vendors would say that a published interface can only be
> removed after two major releases of the software. The first major
> release should suggest that the interface is depricated and should no
> longer be used (the documentation should probably suggest the (new?)
> alternatives too). The following release can then remove the interface.
> While this is painful for the developer, it's necessary for any API
> provider in order to provide a *viable* platform for building upon.
Right idea but I am not too keen on such hard and fast rules.
The issue is sticking to rules and self-policing just doesn't
work for most people.
> Whilst it would also be nice to have an Architecture group that could
> control this sort of thing, I don't think that's at all practical for
> FreeBSD.
I was thinking of an informal group where the *weight* of
your opinion in the group is a function of how well other
respect you and how well you continue making sense! But you
may be right -- one needs a mix of email and face-to-face
meetings to make this work.
Poul-Henning Kamp writes:
> The FreeBSD project is about doing things right, and in doing so
> we expose other pieces of software which didn't do things right.
The trouble is that X's idea of doing things right may not
meet Y's. And X may change his mind a year later. "Right"
is a judgement call. An example, moving an include file in
another directory may be "right" but that just creates a lot
of needless work for very little gain. This is different
from fixing a bug that got exposed (as opposed to a behavior
that broke due to a change in interface).
Terry Lambert writes:
> 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.
The trouble is that if you don't leave such decisions to
developers you need something else.
> Adding another tier of management is probably not the answer
> ("Welcome to the Star Chamber").
I'd say this would *be* the core group or its peer. It would
consist of mostly technical wizards. You can call them stars
if you want! But their role would be to create excitement,
set and explain guidelines and enforce them by mentoring,
cajoling, and so on. and facilitate the evolution process.
> > - 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!
> 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.
I didn't explain well. I meant automatically running a
simple tool like mkid or glimpse or global or something from
the crontab once a week. There will be many false hits but
at least it would be a start.
> To my mind, FreeBSD is losing ground to Linux in a number of
> areas. One of these areas is in published technical references.
> Linux has published technical references, and FreeBSD does not.
> I'm going to argue that the reason these works have been able
> to be written is stabilization of interfaces over time.
I'd have to agree.
To summarize,
The rate of change has been accelerating and it is becoming
harder and harder to get 3rd party apps working or
maintaining them in the working order. While many ports can
be fixed by hard work, I think it is worth debating just what
is "unnecessary" breakage and doing something about it.
We need
- some idea of just who the customers are
- what the freebsd community goals are
- a way to manage the os & ports growth
*while* maintaining as much anarchy as possible. My defn of
freebsd customers is _primarily_ the people who use it; not
just its developers. But the volunteer developers also must
get something back to want to work on FreeBSD. For that a
common vision and excitement needs to be articulated and the
process has to be such that fun far outweighs any grunge
work.
I am not against changes or even breakage, just "unnecessary"
breakage! IMHO interface changes should be carefully vetted.
Pros:
- having to justify can force developers to think harder
- frequently a better option suggests itself after a healthy
discussion
- tradeoffs are considered up front.
- global goals are paid attention
Cons:
- such a vetting process can be a real bottleneck.
- the weight of considering too many things will drive
people away.
- not easy to find people.
I don't know if this can be made to work but I sure hope so!
-- 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?200206050051.UAA07971>