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 09:22:37 +0200 [thread overview]
Message-ID: <83czwmotz6.fsf@gnu.org> (raw)
In-Reply-To: <pxtupyp9tl.fsf@fencepost.gnu.org> (message from Glenn Morris on Fri, 26 Feb 2021 20:40:22 -0500)
> From: Glenn Morris <rgm@gnu.org>
> Cc: Daniel Colascione <dancol@dancol.org>, 42790@debbugs.gnu.org, schwab@linux-m68k.org, lin.sun@zoom.us
> Date: Fri, 26 Feb 2021 20:40:22 -0500
>
> Eli Zaretskii wrote:
>
> > I hope this gets cleaned up, because I think it would be good to have
> > this fixed for Emacs 27.2.
>
> No response; presumably it's now too late.
Yes, pretty much.
> (FWIW I think it would be straightforward for someone whose C isn't
> execrable like mine.)
>
> I really think having some central list of "issues that should be fixed
> before the next release" would help with this kind of thing.
>
> The debbugs blocking mechanism has been used for this previously.
> If you don't like it that's fine, please use whatever you prefer.
> Eg monthly summary postings to emacs-devel, anything.
It's okay to use debbugs blocking, but the problem is, we have no real
mechanism to make sure the blocking problems will be worked on, and
the fact that some aren't is an indirect evidence that those problems
aren't acute. 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.
next prev parent reply other threads:[~2021-02-27 7:22 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 [this message]
2021-02-27 16:05 ` Daniel Colascione
2021-02-27 18:21 ` Glenn Morris
2021-02-27 18:49 ` Eli Zaretskii
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=83czwmotz6.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).