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

Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor



On Sat, Nov 16, 2013 at 12:01:48PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/16/2013 11:43 AM, Mark Brown wrote:

> > It's a package that we've carried since forever and which has a
> > userbase. 

> That's not really an argument. We've also had uae and e-uae

It is an argument; it might be one with which you disagree but that's
not the same thing at all.

> Your first mail came with the argument that you think that
> xemacs is more visually appealing than emacs. Honestly, emacs
> is primarily a tool and not an optical gimmick. Visual
> appearance does not bother most users, I'd guess. Most emacs
> users use the terminal (-nw) mode anyway.

Your assertations here both seem rather strong and unsupported,
especially the idea that people don't use Emacs in graphical mode - it
would be enormously surprising to me if people had abandoned X11 support
en masse.  As for people not caring about the appearence...  if you're
going to be looking at something for the best part of the day it seems
strange that you'd not be interested in how it looks, it's a factor in
usability.

> And the beef I have with xemacs is that it's development
> has factually ceased. Looking at the changes over the past
> months, I see only marginal changes [1] but no real development.

> I never think that's a good idea to upload packages to Debian
> where virtually no upstream development is taking place. The
> risk of RC bugs not getting fixed in time is simply too high.

> I remember fixing RC bugs in several packages in Wheezy during
> the freeze where upstream was no longer available and we had
> to dig through the code and fix the bugs ourselves. I want
> to avoid such situations in the future!

We can always drop packages if they're too buggy; indeed it turns out we
did that for XEmacs in the last release (which I only noticed after
release sadly, much to my distress when I installed a new desktop
recently).  Besides, the risk here seems low, it's not a package that's
using bleeding edge or rapidly developed interfaces that are likely to
change underneath it and obviously Debian's tendency to work with older
versions of software for extended periods means that we have to accept
that even an active upstream might not care about supporting us.

At the end of the day if you're not interested in a leaf package just
ignore it, work on something you do care about instead.

Attachment: signature.asc
Description: Digital signature


Reply to: