[Top][All Lists]

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

Re: Removing bugs from the blockers

From: Dmitry Gutov
Subject: Re: Removing bugs from the blockers
Date: Fri, 13 May 2016 15:48:31 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1

On 05/13/2016 11:36 AM, Eli Zaretskii wrote:

22884 -- IMO we did everything possible, so the bug could be closed

Not closed, but not blocker either. See my last comment in there.

22338 -- shows up only in rare situations, and reasons are not well
         understood; suggest to close

I think there's something left to investigate there, but also not a blocker.

17976 -- actually, a feature request, so should not be blocking

It's a bug, but an old one. It had appeared in a few reports already. Also not a blocker.

20352 -- I thought this was recently resolved, no?

Not sure. But the bug is discussing master, so it's probably not a blocker for 25.1. (If you think it should be closed, please post there).

17693 -- not reproducible on my machine, and no one responded to my
         request for reproduction

Until someone reconfirms, it should be made a non-blocker. Probably close it if it's silent for a couple of months after today.

22440 -- someone who knows about package.el should look at this

23513 -- includes a patch; someone who knows about package.el should
         look at this

I will if nobody else does.

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

Yes, aside from improving the situation with vc-cvs-stay-local and checking that NEWS includes the major changes, I'm not sure what else to do. Look through the manual for outdated information?

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

If Glenn's proposal would work, we could have it in emacs-25. Otherwise, not a blocker.

21871 -- discussion ends with an unanswered question to Stefan

The question seems rhetorical (unless we want Stefan to fix the bug himself).

22527 -- sounds like it should be closed?

It describes a problem, so probably not.

21422 -- my opinion on that is in the discussion; 'nuff said

Actually, I've fixed the biggest pain point there, so it can be made non-blocker.

19717 -- a patch was suggested not long ago; can someone review it?

The patch looks trivial (one should notice right away if it doesn't work). Someone who's used printing.el at least once in their life should try and install it.

22147 -- should be closed, I think


(why is it on the blocking list?)

Maybe because the description made is sound like it's a regression.

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

The blocking list is largely maintained by one person who cannot understand everything.

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

Not sure what do do about that. Revoke commit access? Drop to GNU ELPA or obsolete older and/or niche packages like Viper?

reply via email to

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