Subject: Re: quality, sharing, etc.
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Mon, 28 Aug 2000 13:31:43 +0900 (JST)

>>>>> "Brian" == Brian Behlendorf <brian@collab.net> writes:

    Brian> This is primarily through something called the "ports"
    Brian> collection in FreeBSD, something many of us BSD bigots
    Brian> think is quite cool.

I know a lot of Linux people who think it is very cool too.

The availability of `deb-src' packaging (Debian's answer to sup) is
one reason I haven't been tempted to try any other Linux distro other
than Debian in years.  *BSD, with ports in pure form, is a lot more
tempting.

    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?  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?

Here is a (long) description of the primary problem I see, using
XEmacs as an example.  I'd be very interested to hear from Perl, X11,
GNU Emacs, Apache, GCC, and other large subsystem developers, and from
the distro integrators, whether it matches their perceptions.

The separate ports maintainership is consistently a headache for
XEmacs with respect to FreeBSD, as the FreeBSD patches often do _not_
come back upstream, and often are done in ways _we_ (in our very
finite wisdom) consider architecturally unacceptable.  They often
conflict with changes that we make.  Those XEmacs developers who use
FreeBSD mostly seem to ignore the FreeBSD port.

This is also consistently a headache with respect to Debian GNU/Linux,
for the same reasons.  I know that I ignore the debian/rules with
respect to XEmacs.  They are full of stuff required only to make sure
that multiple "flavors" of GNU Emacs can be simultaneously installed,
and/or otherwise support Debian "Emacs policy," much of which I
actively disagree with.

I can't speak to the rationale for FreeBSD, not being a FreeBSD user.
(Nor are they noisy on the xemacs-beta list. :( )  But with Debian it
goes something like this.

    The Debian GNU/* project has certain overall goals, including
    compliance with international, Debian-, and Linux-specific
    standards, and coexistence of all free software in the Debian
    system.  We can't change or make exceptions to these policies for
    a single upstream project, as it would likely distort the
    packaging for many others.  So, although we try to minimize it,
    these policies may require maintenance of a separate fork, or at
    least separate configurations, installation tools, and policies.

That is, the goals of the Debian GNU developers (a better, more
consistent, easier to install, administer, and use system), and of
XEmacs.org (a better, more consistent, easier to install, administer,
and use XEmacs), often come into conflict.  So far, the Debian
maintainers of the XEmacs packages seem to consider themselves Debian
members first, and rarely actively participate in XEmacs development,
unless there's a bug or conflict that the Debian packaging exposes.
XEmacs developers who are Debian users consider themselves XEmacs
members, and don't show a lot of interest (speaking at least for
myself) in really working on the Debian packaging.

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.  The system integrators (FreeBSD, Debian)
need to know about their packaging standards; once they've learned
them, they often leverage that knowledge by accepting maintainship of
several packages (at least for Debian; I assume in *BSD, analogously,
a maintainer often cares for many ports).  The subsystem developers,
on the other hand, have their own set of project-specific skills, and
wish the packaging issues would go away (ie, "just work").

How do we alleviate it?

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.  Upstream maintainers disappear, or take a
(possibly irrational) dislike to the downstream maintainers or even
whole projects.

And there really are conflicts of interest.  I'm sure that most distro
developers would like to see the rest of XEmacs get FSF-assigned, and
the whole XEmacs project just disappear back into GNU Emacs.  I can't
blame them!  It happens to be legally impractical, and most of the
close approximations would mean throwing away the parts of XEmacs I,
and quite a few other XEmacs developers, consider most important.  The
reverse, the distros requiring their package maintainers to get all
the distro-related infrastructure somehow incorporated in the upstream
product, is even less feasible.

In OSS, that is.  Microsoft has it easy.  If there's a (proprietary)
product that they think would go well with their product line, but
needs closer integration with Windows---they buy the company.
(Nowadays, with their market dominance, they rarely have to go that
far.)  That solves any conflict of interest (except when it kills the
goose that lays the golden eggs).  It works well for Cisco, too.

It isn't going to work for OSS.  We have to work out our compromises
politically.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."