Re: Re Xemacs needs help
Miles Bader <firstname.lastname@example.org> writes:
> On Mon, Mar 01, 2004 at 01:33:49PM -0800, Brian Nelson wrote:
>> All I'm trying to say is that if Emacs CVS snapshots are uploaded to
>> unstable, it should be done with the intention of releasing it in a
>> stable Debian release.
> Hmmm, I'm not sure where I stand on your arguments, but I think your
> conclusion is bogus.
> Emacs cvs snapshots _definitely_ belong in unstable, but I'm not sure they
> belong in stable. Not because they aren't (usually) quite solid, but because
> the advantage they have over released emacs versions -- frequent updates, and
> the ability to reflect where emacs development is heading at the moment -- is
> lost in stable.
> IOW, unstable is _not_ just `stable to be' (though it's _mostly_ that).
That's you opinion, and no offense, but it doesn't matter. The only
opinion that really matters is that of the RM, and he stated his opinion
And in particular:
In order to ease some of the pressure on unstable, we're encouraging
greater usage of experimental. The plan here is that you should upload
the latest, release-quality packages to unstable; and the latest
development packages to experimental. This means daily snapshots, CVS
versions, alphas, pre-releases and so forth. If you're currently
maintaining a foo-snapshot package in unstable, you should consider
dropping the -snapshot, and uploading it to experimental. It also
means you should make an extra effort to ensure that what you put in
unstable is maintained at the quality you'd expect from a Debian
stable release, although obviously with far more frequent changes. You
won't always succeed, unless you're some sort of packaging God, but
that should definitely be your aim.
> Maybe permanent RC bugs an ugly mechanism to achieve this, but it works for
> the most part; is there some way of marking such a bug so that it will be
> obvious that it's not a `real bug' (and e.g. won't freak out people that are
> obsessing over RC bug counts)?
There are other problems as well. Consider that elisp packages
typically depend on "emacs21 | xemacs21". If you package emacs-cvs,
then those elisp packages should support that too, right? But then
those packages would be depending upon a package that would never exist
in stable, which is an RC bug.
> [Experimental, in its current form, is basically a ghetto of sorts: not only
> is it not auto-built, but people by and large don't use it unless they have
> some special interest in a package which they already _know_ is in
> experimental, and there's something of an expectation that packages there
> have problems of one sort or another.]
Isn't that exactly the type of user that Emacs CVS should be targeting?
Don't worry, it's *in*-flammable.