>>>>> "Paul" == Paul Kinnucan <[EMAIL PROTECTED]> writes:
Paul> The biggest problem is that XEmacs org insists on keeping
Paul> every package that they distribute in their own CVS
Paul> repository,
This isn't going to change, see below. If that's a big problem, we're
just going to have to accept lags in distributing JDE. At worst it
should be a couple of months -- a huge improvement over the situation
at the FSF, where they distributed the same version of Gnus for over
two years. Do they distribute JDE at all?
People who need more up-to-date JDE than that do it the traditional
way, and go to the source. The XEmacs package system isn't perfect,
but it does offer that choice. And it is sufficiently successful that
changing it now would cause a lot of pain for an awful lot of users.
Paul> There is a simple (to me) solution to these problems:
Well, yes, of course. We do the work, disorganize our system during
the transition, and you find it simple ;-) Can't blame you for
suggesting it, and it does have certain theoretical appeal....
Paul> 1) Don't require that a package be in the XEmacs CVS
Paul> repository to be distributed with XEmacs.
This is plausible, but not likely to happen in practice.
In theory it would be possible for our Package Release Engineer to
check out anonymously from the JDE repository and drop it in to (a) a
*-pkg.tar.gz package and (b) the SUMO tarball. But keeping only the
Makefile in the XEmacs CVS repository means (1) synchronization issues
between the JDE code the Makefile targets and the Makefile and (2)
even worse problems for non-release-engineers trying to keep up with
both the XEmacs packages and the JDE repository. (Not even the *BSDs
try to do a Makefile-only update-from-remote-CVS-and-build-on-the-fly
AFAIK. And they also force packages into a specific structure.)
This kind of headache is exactly what VC is for. We'd be nuts not to
keep our own repository. In practice, either you check in to the
XEmacs CVS repository, or we do, or we don't distribute. If you don't
want to do the check-ins, OK. Lots of packages are not checked in by
their upstream maintainers. That means your users wait for us to
synch.
The obvious solution to that wait is for you to provide the
jde-*-pkg.tar.gz, as (eg) Kyle Jones does for VM. Not optimal for you
since you have trouble with our installed package structure, but it
will make your users very happy.
Paul> 2) Provide a packaging scheme that allows multifile packages
Paul> like the JDE to be kept together in one root directory.
We do, in the source. For installation...
Easy enough to do, and it was considered when we were streamlining the
Lisp library system. I don't recall exactly why we didn't go that
way. IIRC it's harder to reduce the number of file stats at startup
in that structure. And _every_ XEmacs user waits for those stats.
It's a compromise. Some pain for very large package maintainers
(right now, the main example is JDE). This can be reduced (though not
entirely eliminated) by appropriate coding practices. In return,
_drastically_ (some users observed reductions from like 100 to 15
seconds!) reduced startup times for _every_one at _every_ startup.
Note that this was for the worst possible case: a heterogenous
structure, where some paths were lisp/pkg/*.el and others were
pkg/lisp/*.el. Being flexible for the sake of JDE is the worst
possible choice from the point of view of startup efficiency. We
should change _all_ the packages to the other structure (which could
be about the same in terms of startup in theory, IIRC, but surely
lacks the practical heuristics we've come up with over time for the
structure we actually chose), with concomittent changes to the
Makefiles, our internal path-finding routines, etc.
Lots of craziness, many months of transition time. I guarantee you
those changes won't get past either the 21.1 or 21.4 Release
Engineers. Not to mention the thousands of users who won't update.
So changing the package structure at this point isn't going to happen
merely to reduce distribution lags for JDE.
--
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."
