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

[Stephen Gran]

This one time, at band camp, Cyril Brulebois said:
> 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.

+1

Mark is a long-term DD.  We know he's going to do a good-faith job of
looking after software he uses.  What is the problem?

I am glad that we're moving away from, "every package is a maintainer's
private fiefdom".  But the converse of that is not, "let me nitpick
every maintainer decision to death".  If you're not affected by Mark
uploading xemacs to Debian and maintaining it there for his own use,
then please do be quiet.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

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

[Henrique de Moraes Holschuh]

On Tue, 19 Nov 2013, Russ Allbery wrote:
> Henrique de Moraes Holschuh  writes:
> > On Sun, 17 Nov 2013, Russ Allbery wrote:
> 
> >> Yeah, I know, which is part of why I used it for an example.  I looked
> >> at it yesterday and will probably adopt it at some point when I have
> >> enough free time to do a proper job on the initial upload.
> 
> > File an ITA bug on nvi with that paragraph, please.
> 
> An ITA bug on nvi will block someone else who wants to adopt it, and
> therefore I don't plan on doing that until I'm actually ready to commit to
> adopting it myself.  In the meantime, the orphaned status is correct.

It shouldn't, as long as you title it appropriately and explain that, should
someone else want it, they're welcome.

something like: "ITA: nvi (if someone else wants to adopt it, please do)"

> I read debian-release and debian-qa, so hopefully I'll notice if someone
> starts looking seriously at removing it from the archive.  I'll also copy
> this message to the O bug.

Yeah, that should help.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20131119232721.ga7...@khazad-dum.debian.net

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

[Russ Allbery]

Henrique de Moraes Holschuh  writes:
> On Sun, 17 Nov 2013, Russ Allbery wrote:

>> Yeah, I know, which is part of why I used it for an example.  I looked
>> at it yesterday and will probably adopt it at some point when I have
>> enough free time to do a proper job on the initial upload.

> File an ITA bug on nvi with that paragraph, please.

An ITA bug on nvi will block someone else who wants to adopt it, and
therefore I don't plan on doing that until I'm actually ready to commit to
adopting it myself.  In the meantime, the orphaned status is correct.

I read debian-release and debian-qa, so hopefully I'll notice if someone
starts looking seriously at removing it from the archive.  I'll also copy
this message to the O bug.

-- 
Russ Allbery (r...@debian.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/87vbzorxdj@windlord.stanford.edu

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

[Henrique de Moraes Holschuh]

On Sun, 17 Nov 2013, Russ Allbery wrote:
> Sune Vuorela  writes:
> > On 2013-11-16, Russ Allbery  wrote:
> >> 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.
> 
> > Note that nvi is orphaned, no removal could happen given that many
> > people thinks vim is better.
> 
> Yeah, I know, which is part of why I used it for an example.  I looked at
> it yesterday and will probably adopt it at some point when I have enough
> free time to do a proper job on the initial upload.

File an ITA bug on nvi with that paragraph, please.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20131119171150.ge20...@khazad-dum.debian.net

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

[Barry Warsaw]

On Nov 16, 2013, at 03:32 PM, Mark Brown wrote:

>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, this is getting off topic, but the real history is more subtle,
complicated, and contentious than that.  At least as I remember it.  I was an
early user of Lucid's Energize product and thus Lucid Emacs, the precursor of
XEmacs.  The wikipedia page on XEmacs has a decent, short, and neutral summary
of the history.

Lucid Emacs was groundbreaking for lots of reasons, most visibly its embrace
of X and all the things a real windowing system brings with it.  Syntax
highlighting (font-locking) was another innovation, though when GNU Emacs
adopted similar features they were implemented differently (and at the time, I
felt, not as well, since I did the original patches to support the dual
comment styles of C++ in both editors).  I haven't looked at the guts of
either editor in years.

-Barry


signature.asc
Description: PGP signature

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

[Barry Warsaw]

On Nov 16, 2013, at 12:01 PM, John Paul Adrian Glaubitz 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.

I'm not going to argue for re-inclusion of XEmacs (but I won't argue against
it either - it would be helpful for me testing some Emacs Lisp packages I care
about).  Despite being an old Lemacs and XEmacs user for years, I gave up on
XEmacs back in 2008 in favor of GNU Emacs.

I will dispute the terminal mode usage though.  Most Emacs users I know of do
use the graphical version.

>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 agree that XEmacs's time has come and gone.

-Barry


signature.asc
Description: PGP signature

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

[Russ Allbery]

Sune Vuorela  writes:
> On 2013-11-16, Russ Allbery  wrote:

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

> Note that nvi is orphaned, no removal could happen given that many
> people thinks vim is better.

Yeah, I know, which is part of why I used it for an example.  I looked at
it yesterday and will probably adopt it at some point when I have enough
free time to do a proper job on the initial upload.

We're carrying around a ton of patches, and upstream seems to still exist
although they've been quite dormant, so some investigation will be
required.

-- 
Russ Allbery (r...@debian.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/87zjp2bzp8@windlord.stanford.edu

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

[Fabian Greffrath]

> Please let people maintain packages they use. Even more so when they
> apparently use them on a daily fashion. 

Sounds like a rather strong incentive to revive the package upstream.
Maybe that makes more sense than reintroducing it in Debian as it is?

- Fabian


-- 
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/1384702697.19198.1.camel@kff50

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

[Sune Vuorela]

On 2013-11-16, Russ Allbery  wrote:
> 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.

Note that nvi is orphaned, no removal could happen given that many
people thinks vim is better.

/Sune
 - this post written using vim


-- 
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/slrnl8hc0g.j8.nos...@sshway.ssh.pusling.com

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

[Mark Brown]

On Sat, Nov 16, 2013 at 11:37:00AM -0800, Russ Allbery wrote:

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

The above pretty much exactly encapsulates what made me do this, the
release critical bugs in XEmacs seem easier to deal with than the effort
of changing and the other bugs aren't an issue for me (and seem to be
coming in at a very low rate).  It's possible that at some point Wayland
will mean that I'll need to bite the bullet and find another editor, but
not today.


signature.asc
Description: Digital signature

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

[Mark Brown]

On Sat, Nov 16, 2013 at 07:07:21PM +0100, Andreas Tille wrote:

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

Generally people who do do the right thing but have some reason not to
will mention their reason when they 

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

Had I been aware that there was a problem with the package prior to it
being removed I'd probably have done something about it, ideally prior
to the wheezy release or at least prior to removal from sid.  This would
have enabled me to skip this thread, delightful though it is.  As it was
it was sitting running quite happily and rc-alert doesn't seem to work
for me so I had no idea there was a problem.  

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

Our processes for advertising the pending removal of packages aren't
that great, sadly - this isn't the first time I've noticed something had
a problem only because it vansihed.


signature.asc
Description: Digital signature

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

[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

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

[Cyril Brulebois]

John Paul Adrian Glaubitz  (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

[John Paul Adrian Glaubitz]

On 11/16/2013 08:37 PM, Russ Allbery wrote:
> John Paul Adrian Glaubitz  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

[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

[Russ Allbery]

John Paul Adrian Glaubitz  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)   


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

[John Paul Adrian Glaubitz]

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 p

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

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

[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

[Russ Allbery]

John Paul Adrian Glaubitz  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)   


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

[Vincent Bernat]

 ❦ 16 novembre 2013 13:30 CET, John Paul Adrian Glaubitz 
 :

> 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

[Mark Brown]

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

[Cyril Brulebois]

John Paul Adrian Glaubitz  (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

[John Paul Adrian Glaubitz]

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

[Sune Vuorela]

On 2013-11-16, John Paul Adrian Glaubitz  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

[John Paul Adrian Glaubitz]

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

[Mark Brown]

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

[John Paul Adrian Glaubitz]

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

[Bastien ROUCARIES]

On Sat, Nov 16, 2013 at 1:44 AM, Charles Plessy  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

[John Paul Adrian Glaubitz]

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

[Mark Brown]

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

[Mark Brown]

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

[Paul Tagliamonte]

On Sat, Nov 16, 2013 at 09:44:51AM +0900, Charles Plessy 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.

My comments, unless otherwise noted, are those of me, Paul, *not* the
ftpteam. I wasn't speaking for them, and I surely wouldn't do so without
saying I was.

This is my concern, as a DD, about an old fork, who's utility has been
superseded (IMVHO), and had many open bugs (as anbe points out), being
re-introduced (with nothing but good intentions) only to be removed
again, due to a dead upstream and tons of issues piling up. I don't
question the motives, nor intentions - just the workload in maintaining
something like this.

I'm not going to bother continuing to push this argument, since it's
none of my damn business, I was just trying to feel better about it.

For the record, I'd never abuse my role in the ftpteam to threten
REJECT to win an argument. That would be extremely scummy behavior, and
I'm not doing that now. Never have, never will.

As jmtd points out, I don't even have a package in front of me, so I
really can't comment yet.

I'll let this work it's self out, don't worry about me.


Much love,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : 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

[Andreas Beckmann]

There was a nice bunch of (5-digit) bugs being closed with the removal,
they should be unarchived, reopened and handled properly if xemacs comes
back.

from https://ftp-master.debian.org/removals.txt:

=
[Date: Sun, 13 Oct 2013 09:51:22 +] [ftpmaster: Ansgar Burchardt]
Removed the following packages from unstable:

[...]
xemacs21-packages | 2009.02.17.dfsg.1-1 | source
Closed bugs: 726023

--- Reason ---
RoQA; RC-buggy, unmaintained, dead upstream, not in stable
--
Also closing bug(s): 46985 54387 56180 62287 63340 64290 64723 65469
74787 76139 76938 79127 82417 87623 87723 92073 95825 113489 113598
113599 116355 120985 123882 132544 133894 134426 137251 143163 143363
145279 146844 153113 154971 160740 162587 163957 163958 163961 163962
171150 183004 231059 236070 246638 248545 277451 281891 318020 320339
326783 327259 399483 403611 403771 440460 513574 522670 527389 609603
665253 683700 695799 699543 709501 712316
Also closing WNPP bug(s):
=
=
[Date: Sun, 13 Oct 2013 09:52:05 +] [ftpmaster: Ansgar Burchardt]
Removed the following packages from unstable:

  xemacs21 |  21.4.22-4 | source, all
[...]
Closed bugs: 725883

--- Reason ---
RoQA; RC-buggy, unmaintained, dead upstream, not in stable
--
Also closing bug(s): 39667 40202 40203 42457 47287 47515 49056 50712
51542 54069 54857 55892 56542 57468 60974 61132 61355 61665 62005 63285
63476 63697 63707 63744 64058 64513 64835 65494 66408 67045 67386 68017
72210 74084 74104 75456 75920 75998 76992 77372 77558 78446 78447 79144
80280 81915 83610 85817 88953 90542 92310 94623 98489 98501 99501 100956
101759 102513 104211 104213 104758 105928 106146 107168 107472 107776
108633 109032 109187 109738 110584 110646 110778 110976 112894 113368
113491 113585 114693 114797 117731 118828 122992 126074 126298 126773
128065 133822 134172 134689 135362 135805 142197 142555 143039 143107
143231 143915 144096 144413 145799 145847 146542 14 147171 147426
147556 147830 148750 150692 152878 153224 153778 154725 155424 155740
156144 156513 156515 156874 157858 158314 158573 160377 163219 164734
165503 167335 169016 171263 171433 171824 171830 173557 174489 175050
175234 177269 179649 180895 181129 182062 183119 183866 184197 186294
187609 187999 190163 192072 192075 194161 196524 196870 197301 198485
200717 200781 203879 204817 204852 206118 206381 206530 209157 209594
214638 216775 217341 219098 219809 224373 226734 229822 230792 234193
234204 234392 243683 245389 250314 254734 258572 268832 268833 268835
269244 272243 272452 273817 282275 282610 283159 283415 283569 285990
292438 296339 297916 301750 301752 304800 307617 309747 310799 312919
317725 331315 333845 334830 336445 338066 341005 343083 343330 343663
350003 350081 353077 355026 355348 355349 356584 357045 364433 365927
374198 374808 377962 382427 382434 395209 398756 399269 400859 403425
403877 410482 419922 422731 431252 431910 434468 438513 442428 444614
446137 446889 449294 463684 477623 485736 497262 507866 527966 528900
529607 539834 542492 563714 576747 580611 586785 589138 598320 608691
619367 634666 649686 650581 662557 681407 696146 712355
Also closing WNPP bug(s):
=

Andreas


-- 
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/5286cb0c.9010...@debian.org

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

[Charles Plessy]

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.

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

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

[Dmitrijs Ledkovs]

On 15 November 2013 12:02, Mark Brown  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Mark Brown 
>
> * 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.
>

Why should Debian carry this package?

Which virtual packages are you planning to provide?

Regards,

Dmitrijs.


-- 
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/CANBHLUh4fa7+kwoYBtNyw_FOvKEuCBNxBRS9d-ThL=WX6cg=g...@mail.gmail.com

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

[Mark Brown]

On Fri, Nov 15, 2013 at 10:39:46AM -0500, Paul Tagliamonte wrote:
> 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.

Seems to be due to you setting Reply-To.

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

That's a bug in a different package which I didn't ITP (or look at) yet,
it's just GFDL docs so the simple fix would obviously be to remove the
offending files.  There's only one RC bug in xemacs21 itself which I've
been able to see (a build fail with texinfo5) which is just a matter of
typing to fix.

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

My general approach to these things is to fix bugs as I go.  I don't
have any particular plan for how I'm going to fix things I've not even
looked at or looked for yet but given the lack of either development or
massive changes in the underlying platform I would be astonished if
there were anything insurmountable - the thing that was causing issues
before was that Ohura-san wasn't spending time on the package.

It's going to be quicker and simpler to actually fix the problems than
to go through and make an exhaustive list and analyse them, as Lars
suggested please do assume I'm going to make some reasonable effort to
not upload obviously broken stuff.


signature.asc
Description: Digital signature

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

[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

[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

[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 
: :'  : 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

[Mark Brown]

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

[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 
: :'  : 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

[Mark Brown]

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

[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"  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

[Mark Brown]

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

[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