Why multiple Emacs flavours?

[Rob Browning]

J=E9r=F4me Marant <jmarant@free.fr> writes:

> Rob Browning <rlb@defaultvalue.org> writes:
>
>> If we don't support multiple flavors of emacs, then we force everyone
>> to upgrade as soon as the new version comes out.  At least back during
>
> But isn't it what's happening for most programs in Debian?

Yes, but I think it's accurate to think of Emacs as similar to
something like perl, python, zope, or c++.  It's an entire
environment; it's not like xterm, or ssh, or any other package where
an upgrade mostly just affects the package itself.  So it may be
necessary to continue to provide some level of support for older
versions for some period of time (just as is the case for perl,
python, zope, c++, ....)

>> Supporting both emacs19 and emacs20 for a while gave those people for
>> whom the transition was a problem more time to accomodate the changes,
>> and it wasn't nearly as much work for us as it might have been since
>> we already needed the emacsen-common infrastructure in order to be
>> able to handle both emacs and xemacs.
>
> Package compatibility is a good reason for keeping and old flavour.
> But it shall only be transitionnal IMHO.

Absolutely.  It has always been intended to be transitional, and in
some cases the transition needs to be longer than others.  For
example, the 19 to 20 overlap probably needed to last for a bit, but
that wasn't much less true for the 20 to 21 transition.

The fact that our stable distribution releases have taken as long as
they have hasn't helped, since by default I have just let that be the
way that older flavors are retired.

> I think we should not support old flavour at all. It is not reasonnable
> to spend some time on fixing bugs that have already been released
> in the last stable release.

Agreed, though in practice, I've handled that by just not fixing
things very much in the older packages.  Ideally, one approach I have
recently considered is to just mark the bugs "wontfix -- please
upgrade to emacsXY".

> We can leave the old version in the archive until all emacs packages
> have been ported to this new version.
>
> For instance, once all packages have been ported to emacs22, we can
> remove emacs21: people willing to stay with emacs21 can always grab
> the version from sarge.

Hmm.  Let me think about that.  Up until now, I had just allowed the
older flavor to hang around until the next stable distribution
release, but we could also (as you suggest) just assert that "unstable
is unstable", and remove the older flavor before the next release.

Though one concern I have about that is as follows.  Imagine that the
last version of emacs in sarge is 21.4a-1, and imagine that we get up
to 21.9 in unstable before we transition to emacs22, i.e. 22.1.  If we
drop emacs21 from unstable, there will be users who have much newer
versions of emacs21 installed, versions that are no longer available
anywhere.  I could imagine finding myself in that situation (though
probably not with emacs ;>), and it might be a bit undesirable.

Perhaps that just falls under the general unstable motto, "caveat
emptor" , but if the more recent unstable version of emacs21 was
substantially improved with respect to the one in sarge, then I wonder
whether I'd rather have etch release with the newer emacs21 and the
new emacs22, or just with the new emacs22, and pretend that the
improved unstable version of emacs21 never existed...

Overall though, I'm OK with the general idea here.  I think we'll just
have to take it on a case-by-case basis.  Also, if Debian really does
manage to significantly shorten its release cycle, then the issue
becomes substantially less significant.  In that case, the idea of
letting the release cycle handle the pruning is somewhat more viable.

--=20
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 =3D 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 7=
3A4