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

[Eli Zaretskii <eliz@gnu.org>]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "19070@debbugs.gnu.org"
> 	<19070@debbugs.gnu.org>
> Date: Thu, 12 May 2022 17:25:33 +0000
> 
> > > > Did you look at the change that was actually installed?
> > >
> > > If communicated in the bug thread then I'd know the
> > > answer to the question, and wouldn't need to ask.
> > > It wasn't.
> > 
> > People who want answers to those questions are expected to look in
> > Git.  A URL to do so was posted many times in response to your
> > questions like the above.
> > 
> > Please don't expect people here to post information that you can
> > easily and trivially find out yourself.
> 
> 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.  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.  Honesty has
nothing to do with that; fairness has everything to do with it: you
are being unfair expecting the Emacs maintainers to do the job that
you can do yourself, and easily so.

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