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

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

On 11/16/2013 01:10 PM, Mark Brown wrote:
>> 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

I have yet to see someone who does. I'm a long-time emacs user
and so are many of other developers I work together with and everyone
I know of who uses emacs as their primary editor doesn't use X11
support, you just don't need it in most cases. emacs is powerful through
it's keyboard shortcuts and you are much more efficient and
faster when using them as opposed to navigating through the
menus with your mouse.

> 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.

Well, as I said, if you're really using emacs for what it's renown
for, you don't care about the X11 user interface and the looks
because you use non-windowed mode anyway.

>> 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.

As I explained before, the problem with such packages is that they
can introduce unnecessary (RC) bugs which may delay the release
during the freeze. I am aware of the fact that the release team has
addressed the issue by removing packages from testing now which
have had RC bugs longer than a certain time frame, but I think we should
avoid such situations in the first place. And the fact that a very
limited group of users is using XEmacs doesn't justify the hassle.

If someone is so keen to actually prefer XEmacs over emacs, they
can just download and build the package from source.

> 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.

No, I do care about the whole of Debian and not just about my particular
packages and honestly, it bothers me to no end when I see packages which
have dozens or hundreds of bugs unanswered because no one is stepping
in to fix that. And I think Paul feels the same. I rather prefer to
have a package removed than it being full of bugs, no matter whether
it's a leaf package or not.

A constant quality control of Debian as a whole is important as a whole
for being able to reduce the freeze time as we have learnt in the past.


 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: