Re: ITP: emacs.app -- The GNU Emacs editor on GNUstep
- To: email@example.com
- Subject: Re: ITP: emacs.app -- The GNU Emacs editor on GNUstep
- From: Rob Browning <firstname.lastname@example.org>
- Date: Sun, 21 Dec 2008 16:10:43 -0800
- Message-id: <email@example.com>
- In-reply-to: <firstname.lastname@example.org> (Manoj Srivastava's message of "Mon\, 18 Aug 2008 19\:01\:02 -0500")
- References: <489FEFB4.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Manoj Srivastava <firstname.lastname@example.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
> 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.
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