Subject: Re: quality, sharing, etc.
From: Brian Behlendorf <>
Date: Sun, 27 Aug 2000 22:20:25 -0700 (PDT)

On Mon, 28 Aug 2000, Stephen J. Turnbull wrote:
>     Brian> I think the BSD's all use the same ports collection
>     Brian> concept, but all have their own instantiation of it.  It'd
>     Brian> be nice if these were merged, and I'd hope that was
>     Brian> possible despite the different areas of focus of each BSD.
>     Brian> More broadly, if all the BSD's could be accomodated, then
>     Brian> that might be extendable to other OS's too.
> How is this different from SourceForge in the end?  

*Much* different.  SF is a large repository for any open source project
that wishes to use it, and is "where" the development is supposed to take
place on that project.  By contrast, the ports collection is not where the
development of the code takes place, but where the information about how
to integrate that package into the FreeBSD system (along some filesystem
standards) is maintained.  It's useful to have one person maintain a large
number of ports for a given platform, since consistancy is important;
therefore the amount of time spent on each codebase needs to be as small
as possible.

> I see your
> *trusted* concept, but if the *BSD ports maintainers instead joined
> the upstream teams, wouldn't you then end up with a *trusted* upstream
> project?

That presumes:

a) those ports maintainers are able to join the "upstream team", which
sometimes is just one person who's not interested in having others join
(see qmail)

b) that port maintainer's concept of where things should go are accepted
by the upstream project

c) everyone is happy with being all colocated on a single big CVS tree,
something I don't think is scalable or practical.  In fact many
"ports" are for software that isn't even close to being open source.

> The separate ports maintainership is consistently a headache for
> XEmacs with respect to FreeBSD, as the FreeBSD patches often do _not_
> This is also consistently a headache with respect to Debian GNU/Linux,
> for the same reasons.  

Isn't open source wonderful?  I'm not being sarcastic; I just don't see it
as a bug that the ports modify the upstream code to be specific to the
standards the distribution has.  By the same token, though, *any* bug
report on that modified codebase should be handled first by the
distribution, then passed along to the upstream project once it's clear
it's not related to the patches in the distro.  That would solve your
headaches, I would think.

> I think this division of loyalty problem is natural for large
> subsystems, each with its own (sub-)community of developers, like X,
> Emacs, Perl, and Apache.  

True.  And if you care about bringing those back into the fold, you'll
look at the changes they make and ask yourself if there isn't a more
neutral third path that everyone can agree to.  I know we do that with the
patches in the FreeBSD apache port from time to time.

> It's easy to say "add a standard that no patch to a distro's version
> of a package is admissible unless it's been vetted upstream," but this
> is just not feasible.  

Nor is that open source.