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. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
signature.asc
Description: OpenPGP digital signature
