Re: ITP: emacs.app -- The GNU Emacs editor on GNUstep

[Rob Browning <rlb@defaultvalue.org>]

Manoj Srivastava <srivasta@debian.org> writes:

>         I would suggest that the people who would maintain Emacs for
>  inclusion into Debian releases would do that, at some point (whether
>  they elect to do so before Emacs 23 is released is up to them).
>
>         As I understand it, the current proposal was to package up the
>  development HEAD of  the Emacs tree, and I think this is a fine idea,
>  even if the package is never meant to enter testing, and this is not
>  meant to become the upgrade of Emacs22 or Emacs23 or whatever version
>  of Emacs living in stable/testing.
>
>         I think it is perfectly fine to always keep an emacs-snapshot
>  variant along with whatever the emacsXX flavor do jour in the Elisp
>  packages; this means that there is no more nor less a disruption when a
>  new flavor of Emacs comes along (as a result of a new upstream major
>  release).
>
>         I must be missing the rationale why this is a bad idea.

Here's my perspective:

In an ideal world, since I'm still planning to maintain emacsXY for
the foreseeable future, I would have enough time to create and
maintain an experimental/emacs-snapshot that was always fairly recent.
That would mean that upgrade/transition issues (from say emacs22 to
emacs23) would be dealt with early, and add-on package maintainers
would be able to track the upcoming N+1 packages fairly easily.

I may, in fact, try to do that.  I have more time for Debian Emacs
related issues now, but we'll see.  Note that I also don't have a
problem with someone else maintaining an emacs-snapshot in
experimental, with the caveat that I may or may not end up using their
work directly (partially or wholly), when I eventually package the
next major release -- I suppose time would tell.

Of course, if I didn't end up using someone else's
experimental/emacs-snapshot work directly, then you might end up
asking why people shouldn't just rely on the existing (outside of
Debian) emacs-snapshot packages instead.

I've also been wondering if I might want to switch to a "all in git"
approach (rather than just debian/ in git), and wondering about basing
my work off the Emacs git mirror on savannah.  I suppose that might
make an emacs-snapshot package easier.

In addition, I've paid some attention to your efforts to use git for
your package development, and I'm definitely curious, but I haven't
made any decisions.  The current quilt approach is fairly
straightforward, if not very pretty.

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