[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Re: Possible help with stable Emacs releases.]

From: Robert J. Chassell
Subject: Re: address@hidden: Re: Possible help with stable Emacs releases.]
Date: Thu, 30 Sep 2004 19:15:40 +0000 (UTC)

As I understand, we are talking about two different entities:

  * Debian, who only work with releases from the Emacs developers

  * Emacs, the developers, who work with CVS

The Debian people have been making Debian packages out of Emacs for
years.  They are not planning on becoming Emacs developers.

They have not and are *not* proposing to test a release from _Emacs_

The Debian people are proposing

 1. to continue to make Debian packages out of Emacs releases, and,

 2. occasionally to fix bugs in their packages, which means making new
    Debian packages.

They hope to get their bug fixes from the Emacs CVS development trunk,
but they are not, themselves proposing to do any of the pretesting
needed for a release from _Emacs_ developers.

In other words, the Debian people are *not* proposing to do a
`pretest' as Emacs developers understand it.  They are proposing to
back port some bug fixes to an old version previously released by
Emacs developers.

Currently, the Debian Emacs has a version number that looks like this:


(I just checked using `apt-cache show emacs21'; the full Debian Emacs
version number is `21.3+1-7' but my understanding is that the `7'
merely means this is the 7th Debian package of this series and is as
irrelevant to us as the fourth component of my emacs-version is to

Should the Debian version number remain like that or should it be
changed?  For example, it might be changed to:


and be distinguished from the version number of the current CVS, which
looks like this:


The advantage of a closer connection with the Debian people is that we
can be more confident in our pretests that some of the bug fixes will
work (probabilistically speaking).  This is because the Debian people
will have backported them and tested them on a previous release.

(This does not mean that the changes will be without bugs in the new
release; it means that they worked for the previous release.
Pretesting will still be necessary.  But, probabilistically speaking,
we can be somewhat more confident.)

    Robert J. Chassell                         
    address@hidden                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

reply via email to

[Prev in Thread] Current Thread [Next in Thread]