bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'

[Drew Adams <drew.adams@oracle.com>]

> > If there were an accurate classification of whether
> > a bug was actually fixed, versus not fixed (won't
> > fix), then I wouldn't need to look at anything.
> >
> > In that case, "fixed" or "wont-fix" would suffice.
> > Alas, we now get tons and tons of "fixed"/"Done"
> > for bugs that are not fixed.
> >
> > If a bug is partly fixed, in the view of the fixer,
> > then yes, IMHO it behooves the closing email to make
> > clear to the filer what parts were fixed, i.e., how
> > much it was and wasn't fixed.  That's being honest
> > and straightforward.
> 
> The decision whether and how to fix a bug is a judgment call of the
> development team.

No one said anything to the contrary.  Common sense,
as well as politeness, calls for letting bug filers
know what was done and what was not done.

> We don't post all the details of the fix as part of
> the bug discussion, because it's a burden, and looking in the Git
> repository for the answer to that question is very easy.

Link to it directly in the closing mail.  Copy and
paste the URL - "very easy".

It's also a burden for users to report bugs and
follow up in bug threads.

> Honesty has nothing to do with that;

Honesty has to do with claiming that some "fix" was
"done" when it was not.  That's what honesty has to
do with.

> you are being unfair expecting the Emacs maintainers
> to do the job that you can do yourself, and easily so.

Put a direct link to the result (code or doc) in the
close message.

> > There's nothing odd or abnormal about expecting
> > specific info about how/whether a bug is "fixed".
> 
> Not nowadays, not with the easy access we all have
> to the repository and to the actual fixes.

Easy access for users is a link in the email.
Thank you in advance.