emacs-devel
[Top][All Lists]
Advanced

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

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


From: Ivan Shmakov
Subject: Re: debbugs.gnu.org: is it user-centric or developer-centric?
Date: Wed, 19 Nov 2014 19:27:28 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

>>>>> Glenn Morris <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]