debbugs.gnu.org: is it user-centric or developer-centric?

debbugs.gnu.org: is it user-centric or developer-centric?

[Ivan Shmakov]

	Could someone please clarify on the proper usage of
	debbugs.gnu.org?  Specifically, per my prior experience with the
	Debian BTS, the issues which the developers do not consider
	worth fixing, but which are otherwise valid, are tagged
	‘wontfix’, but /not/ closed.

	The rationale behind that is that the issues both remain visible
	to the /users/ of the package, /and/ are known to be “dealt
	with” (in a way) to the developers.

	Recently, two of my bug reports filed against Emacs (#17959 and
	#19109, specifically) were closed without the issues being
	actually fixed.  This makes them eligible for archiving, which
	will hide them from the (default) BTS view.

	Granted, Debian BTS was established to serve /both/ the
	developers /and/ the users of the package (or at least it’s my
	reading of the Debian Social Contract.)  I thus wonder if my
	experience is applicable to the Debbugs instance run by the GNU
	project; or if that instance is instead targeted primarily at
	developers, and thus merely sharing the knowledge of the
	existing issues (including those arising from some “singular
	usage pattern”, so to say) among the users is out of its scope?

	TIA.

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

 >>> So I'm closing this.

 >> I have no objections to classifying this as ‘wontfix’, but I’d
 >> rather keep this opened for the issue to remain visible to the
 >> community.  (FWIW, http://debbugs.gnu.org/ hides closed issues by
 >> default.)

	I stand corrected: merely closing the bug doesn’t hide it from
	the public view.  However, it makes the bug eligible for
	archiving, and the archived bugs /do/ get hidden by default.

 > That's the point of closing bugs reports -- so that other maintainers
 > don't have to bother with them.

	Wouldn’t ‘wontfix’ be enough for that?

 > Closing again.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: debbugs.gnu.org: is it user-centric or developer-centric?

[Glenn Morris]

Ivan Shmakov wrote:

> 	debbugs.gnu.org? Specifically, per my prior experience with the
> 	Debian BTS, the issues which the developers do not consider
> 	worth fixing, but which are otherwise valid, are tagged
> 	'wontfix', but /not/ closed.

https://lists.debian.org/debian-devel/2014/11/msg00779.html

    [...] if the bug isn't open to discussion, I close it. I think
    that's fairly common across Debian. If it's tagged wontfix but still
    open, that generally means one of two things: either it's still open
    for discussion, but the maintainers are indicating their current
    thinking on it, or it's a commonly-reported false positive (from the
    maintainer's perspective) and they're leaving it open so that people
    will see it in the bug list and see that someone else already
    reported it.

Seems like a good summary to me.

We have 1000s of bugs. Closing ones that are never going to go anywhere
is essential.

Re: debbugs.gnu.org: is it user-centric or developer-centric?

[Ivan Shmakov]

>>>>> Glenn Morris <rgm@gnu.org> writes:
>>>>> Ivan Shmakov wrote:

 >> Specifically, per my prior experience with the Debian BTS, the
 >> issues which the developers do not consider worth fixing, but which
 >> are otherwise valid, are tagged 'wontfix', but /not/ closed.

 > https://lists.debian.org/debian-devel/2014/11/msg00779.html

 > [...] if the bug isn't open to discussion, I close it.  I think
 > that's fairly common across Debian.  If it's tagged wontfix but still
 > open, that generally means one of two things: either it's still open
 > for discussion, but the maintainers are indicating their current
 > thinking on it, or it's a commonly-reported false positive (from the
 > maintainer's perspective) and they're leaving it open so that people
 > will see it in the bug list and see that someone else already
 > reported it.

 > Seems like a good summary to me.

	I do not seem to understand the “isn’t open to discussion” part.
	Is it something along the lines of “I have decided, and my
	decision is final”?

 > We have 1000s of bugs.  Closing ones that are never going to go
 > anywhere is essential.

	FWIW, #19109 already provides a trivial workaround for the
	issue, and I could just as well add one I personally use to
	#17959.  My primary concern is that following the closure, the
	bugs will become less visible, making it more difficult for the
	users having preferences similar to mine to find these
	workarounds.

	My intent is to devise a proper fix for #17959 eventually.
	As for #19109, we seem to have a fundamental disagreement on
	whether Emacs should or should not be allowed to pop a buffer at
	some random time, possibly interfering with whatever the user
	does at the moment.

-- 
FSF associate member #7257  np. Mourning Star — Kamelot … 3013 B6A0 230E 334A

Re: bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> The handling of the news: (nntp:), irc:, and (as it seems) ftp:
> (file:) URI schemes is implemented in such a way that a
> /successful/ url-retrieve call is /not/ in fact guaranteed to
> return a “retrieved document” of any kind.  Consider, e. g.:
>
> (let ((url-proxy-services nil))
> (list (url-retrieve "news://news.aioe.org/alt.sources"
> (lambda (&rest any) (message "news: %S" any)))
> (url-retrieve "irc://irc.freenode.net:6667/x-test-channel"
> (lambda (&rest any) (message "irc:  %S" any)))))
>
> Here, the first call starts up Gnus and opens a *Summary* buffer
> for the group; the second starts Rcirc by default; either call
> returns nil.

I think all these non-http{s,} things in the URL library should be
marked obsolete and removed.  There is very little utility to them (some
have been broken for years without anybody noticing), and they are very
fiddly to maintain.

Anybody mind if I remove them for Emacs 25.2?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Drew Adams]

> I think all these non-http{s,} things in the URL library should be
> marked obsolete and removed.  There is very little utility to them (some
> have been broken for years without anybody noticing), and they are very
> fiddly to maintain.
> 
> Anybody mind if I remove them for Emacs 25.2?

1. Such a proposal should explicitly list each of the "things" you
   propose to mark as obsolete.

2. Marking something as obsolete (deprecating it) does not imply
   that you can remove it.  Normally (although I do know that Emacs
   is not necessarily normal) deprecated "things" remain, and remain
   supported for quite some time before they are desupported.  And
   that means that their supporting code remains (is not removed).

   Or did you perhaps mean remove only from "the URL library",
   and not remove from Emacs?

(All of this said, I probably do not care, personally, what you
do with the unspecified "non-http{s,} things in the URL library"
that you want to remove.)

Re: bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Ted Zlatanov]

On Fri, 25 Dec 2015 20:00:34 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> I think all these non-http{s,} things in the URL library should be
LI> marked obsolete and removed.  There is very little utility to them (some
LI> have been broken for years without anybody noticing), and they are very
LI> fiddly to maintain.

LI> Anybody mind if I remove them for Emacs 25.2?

I'd leave at least the ftp and file protocols.

Ted

Re: bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I'd leave at least the ftp and file protocols.

Mm, yes.  But the rest could be retired, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no