subject:"Bug#729660\: ITP\: xemacs21 \-\- highly customizable text editor"

On Fri, Nov 15, 2013 at 05:05:31PM +, Jonathan Dowland wrote:

 Furthermore, is it not usual practice for ftp master to comment on
 actual packages, rather than theoretical ones? an ITP is intent to
 package. There's no package to critique yet!

Actually I'm starting from the previous packaging so I'll inherit any
issues - there's quite a few things I want to change but it seems the
simplest way to start is to do that and work incrementally to fix the
stuff that doesn't need fixing immediately.


signature.asc
Description: Digital signature

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

On Fri, Nov 15, 2013 at 09:49:49PM +, Dmitrijs Ledkovs wrote:

 Why should Debian carry this package?

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

 Which virtual packages are you planning to provide?

The same set as the package previously did: emacsen, info-browser,
mail-reader, news-reader, www-browser.


signature.asc
Description: Digital signature

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

On 11/16/2013 11:43 AM, Mark Brown wrote:
 On Fri, Nov 15, 2013 at 09:49:49PM +, Dmitrijs Ledkovs wrote:
 
 Why should Debian carry this package?
 
 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
(the Amiga emulators) for ages and they had a user base. Yet,
I filed removal bugs because upstream was no longer existent
and they have been replaced by more modern forks like fs-uae.
There were simply too many bugs that would never get addressed.

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.

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!

I support Paul's stance on this!

Cheers,

Adrian

 [1] http://www.xemacs.org/Releases/21.5.33.html#ChangeLog

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

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

2013-11-16 Thread Bastien ROUCARIES

On Sat, Nov 16, 2013 at 1:44 AM, Charles Plessy ple...@debian.org wrote:
Le Fri, Nov 15, 2013 at 10:39:46AM -0500, Paul Tagliamonte a écrit :

I'd have to look at the RC bugs.

I'm looking for a hard commitment here

Hi Paul,

I think that if you focused on the compliance with the DFSG, then the NEW
queue
could empty quicker.

It is a big problem, and it is also a problem of commitment, of doing one task
well instead of accepting too many responsibilities at the same time. The FTP
team is not able to review packages as efficiently as it did in 2011-2012,
please take action by searching for more volunteers or reforming the system,
instead of loading yourself with extra work.

I know that other developers support the idea of having the FTP team doing
more
checks, but looking at the backlog, this in practice is only wishful thinking,
that boils down to I am happy that somebody else does the work. This at the
moment does not work, therefore a different strategy is needed.

Please ask for lintian autotest like the gfdl one. I will implement gladly.

Bastien

Have a nice week-end,

--
Charles Plessy
Tsurumi, Kanagawa, Japan

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131116004451.ga11...@falafel.plessy.net

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAE2SPAbyeXDRgX8cXfyyLgm1j+EaqsUni5m�nP8advqi=k...@mail.gmail.com

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

On 11/16/2013 12:22 PM, Bastien ROUCARIES wrote:
 I know that other developers support the idea of having the FTP team doing 
 more
 checks, but looking at the backlog, this in practice is only wishful 
 thinking,
 that boils down to I am happy that somebody else does the work.  This at 
 the
 moment does not work, therefore a different strategy is needed.
 
 Please ask for lintian autotest like the gfdl one. I will implement gladly.

Ouuh, that would be awesome! lintian kicks ass!

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52875d5f.6050...@physik.fu-berlin.de

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.


signature.asc
Description: Digital signature

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.

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

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

2013-11-16 Thread Sune Vuorela

On 2013-11-16, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote:
 On 11/16/2013 11:43 AM, Mark Brown wrote:
 On Fri, Nov 15, 2013 at 09:49:49PM +, Dmitrijs Ledkovs wrote:
=20
 Why should Debian carry this package?
=20
 It's a package that we've carried since forever and which has a
 userbase.=20

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

I'm kind of wondering why we are arguing how someone who has
maintained zlib longer than the rest of us have been DDs combined
should spend his time.

Mark has a great and long track record in debian and apparantly needs
xemacs21 to do proper work, why should we put obstacles in the way for
that?

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnl8erf5.j8.nos...@sshway.ssh.pusling.com

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

On 11/16/2013 02:06 PM, Sune Vuorela wrote:
 I'm kind of wondering why we are arguing how someone who has
 maintained zlib longer than the rest of us have been DDs combined
 should spend his time.

I'm not criticizing him, I'm criticizing the idea. Or, putting it
the other way around, I think it should still be allowed to voice
my opinion and doubts even about the plans of someone who has been
in Debian much longer than I am.

 Mark has a great and long track record in debian and apparantly needs
 xemacs21 to do proper work, why should we put obstacles in the way for
 that?

I was in no way doubting that Mark hasn't the necessary skills and
or motivation, that was out of the question and I find it quite
unfair that you move my argumentation into that direction.

My point is that XEmacs isn't really being developed anymore and
I don't think it's a good idea to re-introduce a package which
was just recently removed for that particular reason.

If someone actually came up and said that XEmacs has feature
XYZ that is completely missing in emacs, I might see the point.

But risking bugs which won't get addressed in a timely manner
because upstream doesn't really work anymore can't be justified
with the argument that some people think  the interface of XEmacs
is prettier than the one of GNU emacs.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/528776b4@physik.fu-berlin.de

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

2013-11-16 Thread Cyril Brulebois

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de (2013-11-16):
 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.

I'm always using Emacs under X and never with -nw. Now what?

(Also, your logic is flawed. Powerful keyboard shortcuts don't mean X11
users are clicking through menus…)

Please let people maintain packages they use. Even more so when they
apparently use them on a daily fashion. I'm pretty sure there is actual,
unmaintained junk in the archive to be gotten rid of.

Mraw,
KiBi.


signature.asc
Description: Digital signature

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

On Sat, Nov 16, 2013 at 01:30:01PM +0100, John Paul Adrian Glaubitz wrote:
 On 11/16/2013 01:10 PM, Mark Brown wrote:

  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.

There are other users who do use graphical mode, indeed I was reminded
at the mini-Debconf today that the main reason XEmacs got forked was
that GNU Emacs was too resistant to implementing a GUI.  I guess some
people use menus or whatever but I expect you'll find it's mostly just
to make it look pretty and smoother interaction with other programs.

 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.

There's no cause and effect there, and if the GUI really was inessential
for editors we ought to disable it for them in Debian since it's at best
a waste of time to compile it and a potential source of bugs.

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

This does apply to most of the software in Debian of course...  Debian
has always had a kitchen sink approach to including things, we do have
quite a few architectures as well for example and I'm not sure that our
position as the leading platform for languages such as brainfuck is
considered critical by many.

  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.

Well, there do seem to be a lot of bugs open against the Linux kernel...

 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.

The things that make a meaningful difference to the freeze time are (or
should be) the packages that we can't get rid of for whatever reason and
the packages that sit in the middle of dependency chains.


signature.asc
Description: Digital signature

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

2013-11-16 Thread Vincent Bernat

 ❦ 16 novembre 2013 13:30 CET, John Paul Adrian Glaubitz 
glaub...@physik.fu-berlin.de :

 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.

I am also a long time Emacs user and I mostly use the X11 support. No
menu, no mouse. Without it, Gnus wouldn't be able to display a nice
picture in place of smileys :)
-- 
printk(KERN_WARNING %s: Short circuit detected on the lobe\n,
dev-name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c


signature.asc
Description: PGP signature

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

2013-11-16 Thread Russ Allbery

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:
 On 11/16/2013 01:10 PM, Mark Brown wrote:

 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.

*waves*.

 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.

Your circle of acquaintances is much narrower than you think it is.

 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.

Why do you think running Emacs in graphical mode has anything to do with
menus?  Personally, I run Emacs in graphical mode exclusively but turn off
all of the menus.  I still like having strong mouse support, gutter icons,
cursor shape changes based on whether there is trailing whitespace, full
color and font support that a terminal window can't provide, and so on and
so on.  Some of which XEmacs is still better at than Emacs.

 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.

Complete nonsense.

This thread is ridiculous.  If Mark wants to maintain xemacs21, he gets to
maintain xemacs21.  There's no feasible argument here that its presence in
the archive will somehow hurt our users.  It's a lot of work to maintain,
but if he wants to tackle it, that's the whole *point* of Debian:
packaging the things that we want to use and we want to spend time on.

In the past, we've only rejected things that are almost certainly useless
(because they're strictly inferior to other things in the archive) or
because they have uncorrectable security vulnerabilities or uncorrectable
Policy violations.  None of those are true of XEmacs.  I used it for
years, switched to Emacs only because upstream wasn't moving fast enough
for me, and found the switch disruptive (although I'm past it now).  I can
certainly understand why people wouldn't want to move.  It has some nice
features that Emacs still doesn't have.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqk88e6h@windlord.stanford.edu

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

2013-11-16 Thread Andreas Tille

Hi,

On Fri, Nov 15, 2013 at 05:05:31PM +, Jonathan Dowland wrote:
 On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote:
  I was on my phone, thanks for the advice.
 
 I laboriously quote-post from my phone all the time. Emails should be
 optimised for the reader, rather than the writer.

This is what Paul did:  When writing just a single sentence it might be
reasonable to derive from a role which is good in general but not
helpful in specific cases.  Please try to make reasonable
top-posting-bashings if necessary, not in every case to people who are
known to behave correctly.

 Technically, there are no outstanding RC bugs, all bugs were closed when
 it was removed.

Nice trick to wait for removal of a package to let a bucket of bugs
vanish and start from scratch.  This is wasting the time of previous bug
reporters.  There was a lot of time to fix those long standing bugs if
there would have been any interest in the package and I perfectly share
Paul's point.
 
 Furthermore, is it not usual practice for ftp master to comment on
 actual packages, rather than theoretical ones? an ITP is intent to
 package. There's no package to critique yet!

Ftpmaster had just work to do on the removal (probably not much work)
and if I would be ftpmaster and see an ITP of a just removed package I
would be seriously wondering if people want to play some not so funny
game with me. 

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131116180721.ga25...@an3as.eu

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

2013-11-16 Thread Filippo Rusconi

[[ Not CC'ing bugs because this mail is not about technical stuff ]]

Greetings Fellow Debianists,

On Sat, Nov 16, 2013 at 01:30:01PM +0100, John Paul Adrian Glaubitz wrote:
 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.

How about knowing the shortcuts while having emacs running in a
window?

 
  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.

Come on, John Paul Adrian, how can you assert all these things? Did
you do any survey? Do you really think that your few colleagues
actually are a mirror of a whole community of people using software
for doing lots of different things? I do use plain GNU Emacs with a
grahical interface (that is, with X11, not in console mode) the whole
day, for doing either LaTeX, C/C++, Python, Bash, XML, WhatEver
stuff...

How about letting Mark do his job as a Debian Developer and judge him
on his abilities to fix things? I have absolutely no interest in
defining if XEmacs is worth it in Debian or not. The usage count
should somehow help us. Can we assume that Mark will show a
responsible behaviour? Also, may I ask how what he is trying to do is
so detrimental to the project that we feel like spending time chirping
about it?

Don't we have other interesting Debian-Project-related things to
discuss about ?

 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 there are RC bugs for unused software, the software needs to be
removed and thus does not go into stable. Period. If this removal work
is done well before the freeze, better. Again, let Mark do his job and
check the package in due time.
 
 If someone is so keen to actually prefer XEmacs over emacs, they
 can just download and build the package from source.

Selfish vision, to my humble opinion. That way of thinking defeats the
whole idea of having software to help people do what they want the way
they want.

 
  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.

Mark is indeed trying to fix the bugs, if I understand
correctly. Let's assume he is a responsible and technically sound DD.

Ciao
Filippo

-- 
Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu
Researcher at CNRS and Debian Developer lopi...@debian.org
Author of ``massXpert'' at http://www.massxpert.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131116183915.GC4166@licorne

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

On 11/16/2013 07:39 PM, Filippo Rusconi wrote:
 How about knowing the shortcuts while having emacs running in a
 window?

I assume you haven't used emacs before then? ;) emacs has an excellent
online help and if you don't know a key shortcut, you can hit Meta-x
and type the command in a descriptive long form with auto completion
working (using TAB). Once you have executed the command like this,
emacs will actually show you the keyboard shortcut in its
mini buffer.


 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.
 
 Come on, John Paul Adrian, how can you assert all these things?

Please just call me Adrian ;).

 Did
 you do any survey? Do you really think that your few colleagues
 actually are a mirror of a whole community of people using software
 for doing lots of different things? I do use plain GNU Emacs with a
 grahical interface (that is, with X11, not in console mode) the whole
 day, for doing either LaTeX, C/C++, Python, Bash, XML, WhatEver
 stuff...

No, but emacs is *THE* software when it comes to shortcuts and it's
been like this forever. Just read any book on emacs like the
O'Reilly book with the gnu on it. If you're using emacs and avoiding
the keyboard shortcuts, you're abusing it!

 How about letting Mark do his job as a Debian Developer and judge him
 on his abilities to fix things?

As I said before, I am not criticizing him, I am criticizing his
idea to reintroduce a package that was removedm because both
upstream and Debian lost interest in maintaining it, without
actually providing a valid reason to do so.

And, no, I think the interface is visually more appealing
is not a valid argument for me, sorry.

Russ claimed that XEmacs has some features that emacs doesn't,
however, he wasn't able to mention them.

 I have absolutely no interest in
 defining if XEmacs is worth it in Debian or not. The usage count
 should somehow help us. Can we assume that Mark will show a
 responsible behaviour? Also, may I ask how what he is trying to do is
 so detrimental to the project that we feel like spending time chirping
 about it?

As mentioned before by Paul and Andreas, we're wondering why all
of a sudden Mark is picking up the package while it has been
abandoned all the time and eventually removed. There was no ITA
as far as I know.

 Don't we have other interesting Debian-Project-related things to
 discuss about ?

Do you prefer fighting over init systems instead? ;) If you don't
like the discussion, then don't join it. It should be allowed
to express my opinion and raise some questions. I did neither
insult Mark nor question his skills at any time. I just think
that the idea to maintain something which has just been removed
because maintenance both upstream and in Debian was dead, is at
least questionable.

 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 there are RC bugs for unused software, the software needs to be
 removed and thus does not go into stable. Period. If this removal work
 is done well before the freeze, better. Again, let Mark do his job and
 check the package in due time.

As I said before, I care about the whole of Debian and I prefer
not having too much unmaintained packages in there. And I am not
necessarily talking about the package maintenance but upstream
maintenance.

 If someone is so keen to actually prefer XEmacs over emacs, they
 can just download and build the package from source.
 
 Selfish vision, to my humble opinion. That way of thinking defeats the
 whole idea of having software to help people do what they want the way
 they want.

How is that selfish? Selfish would be not caring about anything but
my own packages and packages that I use. But, again, I care about
the whole of Debian and I simply don't like the idea people using
software which is mostly unmaintained.

 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

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

2013-11-16 Thread Russ Allbery

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:

 Russ claimed that XEmacs has some features that emacs doesn't, however,
 he wasn't able to mention them.

The one that bothered me the most when I switched to Emacs was that XEmacs
narrows the cursor when it as the end of a line, which is very nice for
detecting trailing whitespace.  I came up with a hack for Emacs that
mostly simulates this, but requires running elisp after every single
keystroke.

The faces handling between Emacs and XEmacs is way different, which means
that if you have extensive XEmacs customization, switching to Emacs can be
quite painful.  (It was for me.)

I believe that color handling is better in XEmacs than Emacs, although I
forget what I ran into and have subsequently gotten used to what Emacs
does.

There were various other things that I just did without when I switched
several years ago, but my recollections are hazy plus it's probably not
fair since I switched some time ago and Emacs has gotten better.  (I've
not personally used Emacs 24 yet, for example, so I don't know what it can
do.)  However, I've had discussions with other friends who use the Emacs
family heavily and who are still on XEmacs and they had a long list of
things that didn't work the way they wanted in Emacs.  They weren't things
that affected me personally, so I'm afraid I don't remember the details
beyond thinking at the time that they were reasonable concerns.

Emacs vs. XEmacs is a little like the perpetual vim vs. nvi argument.
They work differently.  Which is better can be a matter of opinion,
speaking as an nvi user who can't stand vim despite the fact that vim
clearly does more and nvi is in deep-freeze maintenance mode.  If you're
used to one of them, switching to the other one is painful.

If someone proposed to remove nvi from the archive because vim is better,
I would be quite annoyed.  If it ever did get removed from the archive, I
would probably adopt it and reintroduce it, because nvi is the editor that
I'm used to for small files and for root editing tasks, I want to keep
using it, and none of the things that are wrong with it are fatal for that
usage.

 As mentioned before by Paul and Andreas, we're wondering why all of a
 sudden Mark is picking up the package while it has been abandoned all
 the time and eventually removed. There was no ITA as far as I know.

Because he just now got around to it?  Because he thought he'd be able to
deal without it but decided he didn't want to?  Because he now has enough
free time to do a proper job of it?

And, rather more to the point, what the hell business is it of yours?
Other Debian Developers don't have to justify their priorities and the
disposition of their time to you.  I think this sort of grilling is quite
demoralizing and frustrating.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3g86sv7@windlord.stanford.edu

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

2013-11-16 Thread Jean-Christophe Dubacq

On 16/11/2013 13:30, John Paul Adrian Glaubitz wrote:

 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.

I, for one, use emacs24 in graphical mode. This means I have a menu up
there, I preview html pages and graphics inside emacs, and other things
like that. I never got to remember the procedure for copy-pasting
something from another window (say, a browser) inside emacs -nw.

However, I find Xemacs terrible, and inferior to emacs24 on all
accounts, and I think xemacs really doesn't need to be in Debian.
But who am I to prevent somebody caring about that package?

Now, if somebody maintaining a package that I don't care for comes
forward and cries for help, so be it. I will not care for it any more.

It's a pity there is so much to be duplicated between Xemacs and emacs.

Out of curiosity, what is in Xemacs and not in a recent emacs?

Sincerely,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

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

On 11/16/2013 08:37 PM, Russ Allbery wrote:
 John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:
 
 Russ claimed that XEmacs has some features that emacs doesn't, however,
 he wasn't able to mention them.
 
 The one that bothered me the most when I switched to Emacs was that XEmacs
 narrows the cursor when it as the end of a line, which is very nice for
 detecting trailing whitespace.  I came up with a hack for Emacs that
 mostly simulates this, but requires running elisp after every single
 keystroke.

Well, emacs marks trailing white spaces as red blocks. At least in
non-windowed mode.

 The faces handling between Emacs and XEmacs is way different, which means
 that if you have extensive XEmacs customization, switching to Emacs can be
 quite painful.  (It was for me.)

Ok. But this isn't really an argument for or against either version,
it simply originates from the fact that both are separate packages.

 I believe that color handling is better in XEmacs than Emacs, although I
 forget what I ran into and have subsequently gotten used to what Emacs
 does.

Hmm, ok. There are rare cases where colors, i.e. contrast is poor on
emacs when editing certain text but it works fine in most cases
for me.

 There were various other things that I just did without when I switched
 several years ago, but my recollections are hazy plus it's probably not
 fair since I switched some time ago and Emacs has gotten better.  (I've
 not personally used Emacs 24 yet, for example, so I don't know what it can
 do.)  However, I've had discussions with other friends who use the Emacs
 family heavily and who are still on XEmacs and they had a long list of
 things that didn't work the way they wanted in Emacs.  They weren't things
 that affected me personally, so I'm afraid I don't remember the details
 beyond thinking at the time that they were reasonable concerns.

I would love to hear these, too ;).

 Emacs vs. XEmacs is a little like the perpetual vim vs. nvi argument.
 They work differently.  Which is better can be a matter of opinion,
 speaking as an nvi user who can't stand vim despite the fact that vim
 clearly does more and nvi is in deep-freeze maintenance mode.  If you're
 used to one of them, switching to the other one is painful.

I didn't know that people were fighting such wars over this. I thought
the original idea of XEmacs was to port emacs to X11 which had not
happened prior to that.

 If someone proposed to remove nvi from the archive because vim is better,
 I would be quite annoyed.  If it ever did get removed from the archive, I
 would probably adopt it and reintroduce it, because nvi is the editor that
 I'm used to for small files and for root editing tasks, I want to keep
 using it, and none of the things that are wrong with it are fatal for that
 usage.

I am not saying that I want to actively remove packages because I don't
like them. Please don't get me wrong. I was just worried about
reintroducing bugs.

 As mentioned before by Paul and Andreas, we're wondering why all of a
 sudden Mark is picking up the package while it has been abandoned all
 the time and eventually removed. There was no ITA as far as I know.
 
 Because he just now got around to it?  Because he thought he'd be able to
 deal without it but decided he didn't want to?  Because he now has enough
 free time to do a proper job of it?
 
 And, rather more to the point, what the hell business is it of yours?
 Other Debian Developers don't have to justify their priorities and the
 disposition of their time to you.  I think this sort of grilling is quite
 demoralizing and frustrating.

Jeez, no need to freak out. I elaborated my reasons and I was just
asking questions. I am not hampering anyones freedom whatsoever,
I am just worried about bugs in general because I remember how utterly
annoying the last freeze was because of this.

And, really, I didn't start this discussion, there is no need to solely
bash me now for asking questions.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5287ce68.9040...@physik.fu-berlin.de

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

2013-11-16 Thread Cyril Brulebois

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de (2013-11-16):
  And, rather more to the point, what the hell business is it of
  yours?  Other Debian Developers don't have to justify their
  priorities and the disposition of their time to you.  I think this
  sort of grilling is quite demoralizing and frustrating.

Totally agreed with Russ.

 Jeez, no need to freak out. I elaborated my reasons and I was just
 asking questions. I am not hampering anyones freedom whatsoever, I am
 just worried about bugs in general because I remember how utterly
 annoying the last freeze was because of this.
 
 And, really, I didn't start this discussion, there is no need to
 solely bash me now for asking questions.

The past few mails of yours have been way out of line. It might be a
good idea to concentrate on other topics, and let people maintain stuff
they care about / feel they need to get work done.

KiBi.


signature.asc
Description: Digital signature

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

2013-11-16 Thread Jonathan Dowland

On Sat, Nov 16, 2013 at 01:30:01PM +0100, John Paul Adrian Glaubitz wrote:
 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.

I've been trying (and failing) to get back into using Emacs for ten
years. However back when I did (before I learned and switched to vi)
I used to use graphical mode exclusively, for three reasons: better
colour support (I guess mostly addressed now); non-fixed width font
support; finally, some keyboard shortcut combinations I wanted to use
aren't supported in terminals (variations on alt/ctrl tab iirc)

Mouse and keyboard combined are a very rich UI, one does not need to
limit oneself to pointing and clicking on menus with a mouse to use
it effectively.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131116214505.ga11...@bryant.redmars.org

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

Package: wnpp
Severity: wishlist
Owner: Mark Brown broo...@debian.org

* Package name: xemacs21
  Version : 21.4.22
  Upstream Author : XEmacs development team
  URL : http://www.xemacs.org/
  License : GPL
  Programming Lang: C, elisp
  Description : highly customizable text editor

XEmacs is a full fledged programming language with a mail reader,
news reader, info browser, web browser, calendar, specialized editor
for more programming languages and other formats than most people
encounter in a lifetime, and much more.

While develoment on xemacs is very slow these days I find it much more
visually pleasing than GNU emacs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131115120218.16184.65842.reportbug@finisterre

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

2013-11-15 Thread Alberto Garcia

On Fri, Nov 15, 2013 at 12:02:18PM +, Mark Brown wrote:

 * Package name: xemacs21
   Version : 21.4.22

Wasn't this removed just one month ago?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725883

Berto


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131115122950.ga12...@igalia.com

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

On Fri, Nov 15, 2013 at 01:29:50PM +0100, Alberto Garcia wrote:
 On Fri, Nov 15, 2013 at 12:02:18PM +, Mark Brown wrote:

  * Package name: xemacs21
Version : 21.4.22

 Wasn't this removed just one month ago?

Yes, this is why I'm ITPing it.


signature.asc
Description: Digital signature

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

2013-11-15 Thread Paul R. Tagliamonte

Out of curiosity, how do you plan on solving it's six rc bugs?
 On Nov 15, 2013 9:10 AM, Mark Brown broo...@debian.org wrote:

 On Fri, Nov 15, 2013 at 01:29:50PM +0100, Alberto Garcia wrote:
  On Fri, Nov 15, 2013 at 12:02:18PM +, Mark Brown wrote:

   * Package name: xemacs21
 Version : 21.4.22

  Wasn't this removed just one month ago?

 Yes, this is why I'm ITPing it.

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

On Fri, Nov 15, 2013 at 09:17:34AM -0500, Paul R. Tagliamonte wrote:

Don't top post.

 Out of curiosity, how do you plan on solving it's six rc bugs?

Yes, of course.  Well, the one that was there when I looked is fixed,
I'll see if the BTS tells me about any open ones after the reupload.


signature.asc
Description: Digital signature

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

2013-11-15 Thread Paul Tagliamonte

On Fri, Nov 15, 2013 at 03:01:46PM +, Mark Brown wrote:
 On Fri, Nov 15, 2013 at 09:17:34AM -0500, Paul R. Tagliamonte wrote:
 
 Don't top post.

I was on my phone, thanks for the advice.

  Out of curiosity, how do you plan on solving it's six rc bugs?
 
 Yes, of course.  Well, the one that was there when I looked is fixed,
 I'll see if the BTS tells me about any open ones after the reupload.

No, I don't think it's wise to let this back in the archive before you
know how you're going to deal with *why* it was removed. God knows we
the ftpteam doesn't need more work (processing this from NEW to only rm
it a few short weeks later).


Before you put this in NEW, how do you plan on fixing the outstanding RC
bugs?

Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte paul...@debian.org
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

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

On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote:

 Before you put this in NEW, how do you plan on fixing the outstanding RC
 bugs?

By making changes to the software.


signature.asc
Description: Digital signature

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

2013-11-15 Thread Paul Tagliamonte

On Fri, Nov 15, 2013 at 03:25:16PM +, Mark Brown wrote:
 On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote:
 
  Before you put this in NEW, how do you plan on fixing the outstanding RC
  bugs?
 
 By making changes to the software.

No need to CC me, I'm subscribed.

This doesn't fill me with confidence that any of the reasons that it was
removed will be fixed.

I'd have to look at the RC bugs, but it's not out of the question that
would get xemacs a REJECT from NEW if they're not handled. At first
glance, #695799 appears to be one such bug.

so, again, how will you fix the open bugs before you upload to
NEW? Which bugs are you planning to fix?

I'm looking for a hard commitment here, Mark.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte paul...@debian.org
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

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

2013-11-15 Thread Lars Wirzenius

On Fri, Nov 15, 2013 at 03:25:16PM +, Mark Brown wrote:
 On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote:
 
  Before you put this in NEW, how do you plan on fixing the outstanding RC
  bugs?
 
 By making changes to the software.

This discussion is getting a tad too antagonistic, maybe? May I
suggest someting?

* The FTP team has valid concerns about re-introducing a package
  that's already been removed, partly due to not being maintained well
  by a previous maintainer.

* Mark's a long-time Debian developer. We can expect him to do his
  best to fix the package before uploading, without interrogating him
  on the details at ITP time.

* Backups are tasty snacks. Let's all run a backup now.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131115154543.GG8314@holywood

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

2013-11-15 Thread Jonathan Dowland

On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote:
 I was on my phone, thanks for the advice.

I laboriously quote-post from my phone all the time. Emails should be
optimised for the reader, rather than the writer.

 No, I don't think it's wise to let this back in the archive before you
 know how you're going to deal with *why* it was removed. God knows we
 the ftpteam doesn't need more work (processing this from NEW to only rm
 it a few short weeks later).

There were four stated reasons for its removal, and RC-buggy was just
one. Unmaintained was another, and lack of maintenance is one sure fire
way to make sure that RC bugs aren't fixed. One that Mark is proposing
to address by maintaining the package.

 Before you put this in NEW, how do you plan on fixing the outstanding RC
 bugs?

Technically, there are no outstanding RC bugs, all bugs were closed when
it was removed.

Practically, of course there are likely to be issues that were opened
against the old package which will apply to the new one. But how did you
get to the figure 6 (elsewhere?) Is that Moritz's count from #725883?
How do you know which of those 6 are problems in the source, rather than
problems in the packaging (which may not be inherited by Mark's
packaging efforts?)

Furthermore, is it not usual practice for ftp master to comment on
actual packages, rather than theoretical ones? an ITP is intent to
package. There's no package to critique yet!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131115170531.ga13...@bryant.redmars.org

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