Re: [gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers
Stephane Bortzmeyer <bortzmeyer@pasteur.fr> writes:
> [debian-emacsen removed, because I don't like to send mail to lists I don't
> read. Also, I don't want to talk about Emacs-specific problems.]
>
> [Per included in because I don't like to criticize people who are absent.]
>
> On Thursday 1 July 1999, at 20 h 37, the keyboard of Rafael Laboissiere
> <rafael@icp.inpg.fr> wrote:
>
> > From: Per Abrahamsen <abraham@dina.kvl.dk>
> > Newsgroups: gnu.misc.discuss,gnu.emacs.gnus
> > Subject: Free software: Packagers vs Developers
> > Date: 01 Jul 1999 19:03:38 +0200
>
> > versions of free software. All the major Linux distributions does it,
> > perhaps to gain a competitive advantage, but Debian seems to be worse
> > than the rest.
>
> Per, could you elaborate on that?
Not in a useful way. I hear developers swear about Debian more often
than about e.g. Red Hat, despite Red Hat being more widespread.
> As a Debian user, I do not see this and, actually, one of the most
> common things that people criticize in Debian is quite the opposite:
> they find that many packages use an old version (because the Debian
> maintainer is too careful, or too lazy, to upgrade).
What developers want is for users to use the latest released version.
Obviously we will have to live with distributions packaging too old
versions, that is the nature of the game. But there is no reason we
should have to live with distributions packaging too new versions.
Some *users* may want the hottest newest stuff, withouit going through
all the trouble of downloading it from the developers and subscribing
to their mailing lists. Well, fuck them.
> > Perhaps because they have so many package maintainers
> > (500+), each of whom feel the need to make a difference.
>
> Pure theory. Again, I would like facts.
The best you can hope for is theory backed by anecdotical evidence,
unless someone is going to make a survey amongst software developers.
Debian has a maintainer for AUC TeX. It suggests to _me_ that you
have a way to fine grained structure.
> Among all the packages I maintain, the only one which is really
> decoupled from upstream is queso, because the upstream maintainer do
> not reply to any mail, even containing patches.
Neither do I. I have no idea what to do with a bug report or patch
comming from a middleman, who neither have the same direct experience
of the problem as the user, nor the same knowledge of the code as the
developer. Of course, I could try to contact the user directly, hope
that he is willing to explain everything again, figure out what code
he has received from Debian, try to figure out if the problem is due
to my code or the Debian mangling, and then start from there.
Instead, I just curse Debian for sabotaging my work, and delete the
mail.
> That's why the queso package of Debian is 64-bits clean, unlike the
> upstream tarball, works with rejecting routes, unlike the upstream
> tarball, etc.
Maybe if there hadn't been a Debian package with all these attributes,
the _real_ queso would do all this. Benefitting _everybody_, not just
Debian users.
> But our changes are available publically, in the source package, so,
> even if the Debian developer does not forward patches, anyone can
> submit them upstream.
Patches are almost useless, what develops need are quality bug reports
comming directly from the affected users, running a version of the
code identical to what is released, except for changes made by the
user himself. _If_ these are combined with a patch, that is an extra
bonus.
> > I know that we developers have to live with _some_ changes being made
> > in order for the software to work together in a distribution, but it
> > would be nice if some ethical guidelines among packagers could be
> > developed to supplement the current Debian rules, like:
>
> I suggest, both to upstream authors and to packagers to not rely on
> *ethics* but on *rules*: there is the licence (if the Alpha release
> is distributed with a different licence, which prevents
> redistribution, follow that licence), the Debian policy (which
> prevents point number 3, see under), etc.
I prefer ethics and social conventions to rigid rules. See for example
<URL: http://www.tuxedo.org/~esr/writings/homesteading/>
for some. I believe these are what makes the free software community
work. And no, I don't believe alpha releases should be unfree.
Sometimes developers become inactive, or development for other reasons
have to split. It was a good thing Lucid Emacs and egcs could start
from the latest development sources, instead of having to backtrack to
the (very old) released versions.
Both Emacs and gcc ran under a closed development model, even if the
alpha releases are free. The open development process most projects
use now is a good thing, and can work if packagers show developers the
respect not to release unreleased versions of the software.
> > 1) _Never_ distribute alpha releases.
>
> This cannot be turned into a formal rule, because there is no naming
> standard.
And?
> I prefer to use an alpha of procmail than a final release of MSIE.
Then join the procmail development, or suffer.
Or ask the author, if he thinks it is ok to distribute pre-releases of
procmail.
> > 2) _Never_ distribute improved versions.
>
> If we cannot do that, it is no longer free software. Period.
Sure it is. It is the difference between legal and ethical again.
RMS goes to great length to prevent Emacs 20.4 prereleases from
reaching other people than those on his lists of pretesters. But he
doesn't rely on the force of law for this.
> And if the Debian changes are really an improvment (patches can
> introduce new bugs, too), I appreciate them.
Sure, all the users of a specific distribution will appreciate the
enhancements. It is the free software community as a whole who
suffers.
> > 3) _Never_ distribute with different "user preference" options
> > than the default.
>
> No. This would suppress the whole idea of a distribution.
Then the whole idea of a distribution sucks.
> It means we should ship Netscape with home.netscape.com as the
> default?
There _are_ some options that are intended to be set in order for the
software to play well in the environment where it is installed. If a
distribution has `qmail' as its default mail transport, the mail
agents should be set for that as well. I don't consider those for
"user options", but options for "site administrators". Ask Netscape
what kind of option the above is. User options are such thing as
enabling auto fill mode or font lock in Emacs.
> Middlemen, which seems so despised, have a role: they write man
> pages when they are missing (most of my packages), they fix bugs,
> because we have a good Bug Tracking System, which most upstream
> authors do not have, they port, because Debian runs on many systems,
> etc.
They should join the development project then, and not be middlemen
any more. All the above (except the bug tracking system) is better
handled at that level.
Those project that _needs_ a formalized bug tracking system has one.
Most don't, a mail folder containing "open bugs" is all that is
needed.
> Reading back my work on my packages, I can feel confident that we
> are not social parasits. We add value.
You add value, but at the wrong place. You add it in the middle, thus
only reaching a branch of the tree, instead of the top, where you
would reach the entire tree. And by adding the value in the middle,
you make it less likely that the value will reach the top. The users
in your branch won't see the need.
"Oh, you need a 64bit clean version. Just use Debian."
Reply to: