Re: Removing bugs from the blockers

[Dmitry Gutov <dgutov@yandex.ru>]

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

Probably.

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

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