From: Eli Zaretskii <eliz@gnu.org>
To: Glenn Morris <rgm@gnu.org>
Cc: schwab@linux-m68k.org, 42790@debbugs.gnu.org, lin.sun@zoom.us
Subject: bug#42790: [PATH] 27.1; Add version info into file name "emacs.pdmp" to avoid mismatch pdmp file
Date: Sat, 27 Feb 2021 20:49:48 +0200 [thread overview]
Message-ID: <831rd1ny5v.fsf@gnu.org> (raw)
In-Reply-To: <xba6rpe5h9.fsf@fencepost.gnu.org> (message from Glenn Morris on Sat, 27 Feb 2021 13:21:54 -0500)
> From: Glenn Morris <rgm@gnu.org>
> Cc: dancol@dancol.org, 42790@debbugs.gnu.org, schwab@linux-m68k.org, lin.sun@zoom.us
> Date: Sat, 27 Feb 2021 13:21:54 -0500
>
> Eli Zaretskii wrote:
>
> > So delaying a release indefinitely due to such problems doesn't sound
> > wise to me: we are already accused of having too long release cycles.
>
> You control when a release is made. A flag in the bug database can't
> prevent you from making a release. But if you don't have any mechanism
> for communicating to people what you think the important issues are,
> they are likely to get lost in the noise (certain individuals can report
> a dozen trivial bugs a day).
I think I do have a mechanism for communicating that: the 2 mailing
lists we use, and the bug tracker. What better mechanism can you
propose that will make sure the messages don't drown in the noise?
You proposed announcing on emacs-devel, but with the level of noise
present there lately, I'm not sure _I_ don't lose important messages
there; I have no reason to believe posting there will get the
attention of the unknown parties who ignored this particular bug since
it was reported.
> Personally I have no idea what issues remain to be fixed before 27.2
> can be released.
None. We are all set. The next tarball will be a RC.
next prev parent reply other threads:[~2021-02-27 18:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-10 3:21 bug#42790: [PATH] 27.1; Add version info into file name "emacs.pdmp" to avoid mismatch pdmp file via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-08-10 8:27 ` Andreas Schwab
2020-08-10 9:24 ` via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-16 1:03 ` Glenn Morris
2020-11-20 15:07 ` Eli Zaretskii
2021-02-27 1:40 ` Glenn Morris
2021-02-27 7:22 ` Eli Zaretskii
2021-02-27 16:05 ` Daniel Colascione
2021-02-27 18:21 ` Glenn Morris
2021-02-27 18:49 ` Eli Zaretskii [this message]
2021-07-21 13:51 ` Lars Ingebrigtsen
2021-09-30 1:33 ` Glenn Morris
2021-09-30 6:47 ` Lars Ingebrigtsen
2021-10-11 12:04 ` Lars Ingebrigtsen
2020-08-14 14:53 ` Lars Ingebrigtsen
2020-08-15 4:52 ` via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-08-15 10:42 ` Lars Ingebrigtsen
2020-08-15 10:47 ` Lars Ingebrigtsen
2020-08-16 0:30 ` via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831rd1ny5v.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=42790@debbugs.gnu.org \
--cc=lin.sun@zoom.us \
--cc=rgm@gnu.org \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).