Re: CVS is the `released version'

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> David Kastrup writes:
>
>  > Please take a look at how the XEmacs package system works.  It
>  > has a central repository.  It tends to distribute outdated or
>  > non-working code because the people maintaining the central
>  > server tend to be not the same creating the packages.
>
> I wish you'd stop generalizing from your experience, which is
> limited to AUCTeX and is unrepresentative of the general experience.

I don't see how it would be unrepresentative.  Please name some
packages where

a) the upstream author has not taken upon himself the burden of
becoming an XEmacs developer including write access to the XEmacs
CVS repository and learning the structure of the package build system

b) the package is kept reasonably uptodate

Could you name externally distributed packages (useful for other Emacs
variants) where the structure of the XEmacs package is not different
from what works unmodified for the distribution of other versions?
There is X-Symbol, but its Emacs install procedure is a hand-crafted
process that is made more complicated by the XEmacs package structure.

> Furthermore, your reporting of the features and operation of the
> XEmacs package system bears almost no resemblance to the reality.
>
> So let's take a look at how it does work.
>
> In fact, most of our packages (that are not maintained by the GNU
> Emacs project) are maintained by their upstream maintainers.  They
> generally simply make a commit to the XEmacs CVS repository,

See?  You require
a) the upstream developers to have CVS write access
b) the package to be structured for the XEmacs packagae CVS tree which is
c) completely different from the actual package layout in the
   installed tree, meaning that this particular layout is useless
   _except_ as part of the _XEmacs_ package system.

> which starts the release process using XEmacs resources, including
> rolling and announcing tarballs, a pretest period, and a second
> announcement when the pretest is over and the release is promoted to
> "public release" (of the XEmacs package).  Only if bugs are
> reported, or if the maintainer wishes to give special instructions
> (eg, more commits are coming, don't release yet) is there need for
> anything more than a cvs commit by upstream.  (AUCTeX differs
> because for many years its upstream maintainer has been publicly at
> odds with the XEmacs project and has explicitly claimed that the
> user who has volunteered to maintain the XEmacs package is
> unqualified,

That's what the _user_ himself has stated several times, yet he has
seen little help.  Don't blame me for repeating Uwe's statement.  And
it is not like I have ever discouraged Uwe for his work.  I have
rather complained about the lack of help he is seeing from XEmacs
developers.

> and thus has forfeited control over our package to our volunteer.)

Stephen, cut the propaganda.  None of the XEmacs developers could be
bothered updating AUCTeX which had fallen _several_ years behind for
that reason.  I asked _repeatedly_ on the XEmacs developer list, over
a long period.

Finally an AUCTeX user, Uwe, volunteered to _try_ his hand and he has
repeatedly stated himself that he was quite out of his depth.
Nevertheless, he managed to get out some releases with a large
time-delay.  It was, however, relatively obvious that he was not
getting much help from XEmacs developers.  Since preview-latex already
had the infrastructure for building an XEmacs package layout included
(from the time an XEmacs developer helped porting it), when we merged
preview-latex into AUCTeX, we have kept this infrastructure intact.
One of the motivations was to be able to produce a complete XEmacs
package as a _target_ for those having to maintain the XEmacs package
in the XEmacs CVS manner.

preview-latex is not a simple package, and the installation process
has a lot of flexibilities.  Nevertheless, we have been able to come
up with a configuration (after several iterations) that produces a
ready-to-run XEmacs package usable for pretty much all configurations.

In spite of having our automated build process to take as an example,
in spite of having a ready-made package (which according to XEmacs
terminology is complete (citing the GPL) "with all the source code for
all modules it contains, plus any associated interface definition
files, plus the scripts used to control compilation and installation
of the executable") and in spite of both Uwe as well as another XEmacs
developer trying, they have not been able to create the files and/or
process of reproducing the package which we already provide in a final
form.

> Regarding centralization, if you want *us* to distribute packages
> with storage and bandwidth contributed to *us* and want *us* to do
> the work of rolling the tarballs and so on, then indeed we do insist
> on checking in to our CVS.

It does not work since the CVS requires a completely different
directory layout from the installed package.  So it is required to
have
a) a source tree modeled after the XEmacs CVS package source tree
b) a final package layout modeled after the XEmacs package layout.

If you have just b), you can't transform it into a) (or we would have
had an uptodate AUCTeX distributed long long ago).  And if you don't
use the rigid XEmacs package tree layout for going to b), you can't
get to a) easily either.

And this is simply a mistake.

Now the current approaches I see with package systems for Emacs at
least avoid the mistake of demanding a source package layout that is
fundamentally different from the finished package layout and can't be
reproduced from the latter.

That is one design mistake less to cater for.

But the centralized repository requirement, in my book, is another
that is asking for trouble.

> For almost all changes to packages, it's simply a matter of copying
> over the new version to a checked-out XEmacs tree, and typing "cvs
> commit -m 'Release of version X.Y.Z.'"  in the package subtree of
> the XEmacs tree.  This is no different from getting your package to
> be released as an official Emacs library, using GNU resources: you
> have to check into the GNU CVS repo.

Which does not have a different layout from the distributed packages
and does not require separate description files and Makefile rules.

Still, the target of a package system, if any, is _not_ to require
including everything into Emacs.  So saying that your system is as
easy as just dropping everything into Emacs (which it isn't) is
tantamount to saying that its complications are not offset by making
maintenance simpler.

> Note that for this reason Tom Tromey's package.el will likely be
> quite popular with upstream maintainers, compared to the XEmacs
> system.

Well, there is nothing wrong in trying to avoid what I consider design
mistakes in the XEmacs system.  Certainly package.el seems like an
improvement over the XEmacs system for most uses.  That does not mean
that one should not try still making it better for common use cases
while one is still in the design phase.

>  > If some package is provided upstream, we want to have it directly
>  > usable from its default download location.
>
> XEmacs's package system has that feature, and has always had it, by
> design.  Cf VM.

Uh no.  VM does not tell the package system where its canonical
download location is supposed to be.  One has to manually configure
that.

> There's nothing to stop you from distributing a package compatible
> with our download and install UI.  In fact, AUCTeX, like VM, does.
> The VM and AUCTeX sites are not available from the package
> configuration menu, but that's only because Kyle doesn't
> particularly want the traffic, while there are "personal issues"
> involved in the lack of an AUCTeX entry.

What personal issues?

> However, in the end I have to agree with Richard Stallman.  One big
> problem (for GNU) with a package system is that it facilitates
> distributed development and permits a general topology (rather than
> a star) for the distribution network.  Thus it undermines the
> incentive to work in the context of the Emacs project and to assign
> code to the FSF.  That's inconsistent with my understanding of the
> goals of GNU, and therefore of the Emacs project.

Yes and no.  Part of the strength of Emacs is its extensibility which
leads to a large amount of one-shot code for special solutions that
really has no sensible place in a centrally maintained repository, and
which is not strategically important to the GNU project.  Being able
to provide such code in a form which could easily be pulled into an
Emacs without much manual work would be a boon.

> I conclude that until distributed development becomes an explicit
> goal of the Emacs project, a package system is generally
> counterproductive to the objectives it espouses (by which I mean
> advocating free software and supporting organizations in the free
> software movement, and developing Emacs itself as opposed to third
> party libraries).

I am more thinking in the form of "disjoint" rather than "distributed"
development.  Stuff which you might very well decide you don't need.

-- 
David Kastrup