[Top][All Lists]

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

Re: Removing bugs from the blockers

From: Eli Zaretskii
Subject: Re: Removing bugs from the blockers
Date: Fri, 13 May 2016 11:36:49 +0300

> From: Dmitry Gutov <address@hidden>
> Date: Fri, 13 May 2016 00:35:37 +0300
> 20420 is not very important, and likely wontfix.
> 22107 - same.
> 22527 is not very important.
> 19479 is a crapfest, and is unlikely to be fixed soon (we haven't even 
> fixed the basic signature verification functionality yet, see the other 
> bugs, and that's shameful).

Agreed.  Additional triage:

22434 -- caused by fixing another bug, affects a minor feature, and
         won't be fixed unless someone motivated works on it
23144 -- we don't know how to fix it; maybe talking to GTK maintainers
         could help
22884 -- IMO we did everything possible, so the bug could be closed
22338 -- shows up only in rare situations, and reasons are not well
         understood; suggest to close
17976 -- actually, a feature request, so should not be blocking
20352 -- I thought this was recently resolved, no?
21489 -- is most probably the result of refactoring of keystroke
         echoing, and probably won't be fixed
17693 -- not reproducible on my machine, and no one responded to my
         request for reproduction
23360 -- does anyone have a better idea than introducing a variable to
         control the affected code (which is mostly unneeded, but
         sometimes is)?
22440 -- someone who knows about package.el should look at this
21650 -- MH-E bug, handled there
23513 -- includes a patch; someone who knows about package.el should
         look at this
22795 -- not reproducible, should probably be closed, as I've not
         heard from the OP for a long time
22465 -- includes a patch that should be applied, and the bug closed
20247 -- appears in very rare situations, so shouldn't block the
21182 -- the blamed commit seems unrelated, so should probably be
         tagged not reproducible
19548 -- is worded too generally, and is therefore hard to work on;
         perhaps Glenn could make post specific complaints, which then
         could be handled one by one
23050 -- is a manifestation of an old bug 18125, and also includes 2
         ideas for solution; also, is specific to a certain workflow,
         so there's a workaround
21871 -- discussion ends with an unanswered question to Stefan
22527 -- sounds like it should be closed?
21422 -- my opinion on that is in the discussion; 'nuff said
19717 -- a patch was suggested not long ago; can someone review it?
21874 -- sounds like it should be closed?
22295 -- undo-related, I hope Phillip will be able to look into it
22147 -- should be closed, I think (why is it on the blocking list?)

My conclusion from reviewing these bugs is: I don't really understand
how come some of the bugs were designated as "blocking".

A more general conclusion (from both these and other bug reports) is
that we tend to break valid use cases when we refactor some core parts
of Emacs, and the people who worked on refactoring are not always
willing to work on cleaning up the breakage it caused.  For example,
the above list includes a few bugs for which the offending commit was
identified, but the guilty parties don't seem to be eager to work on

reply via email to

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