From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: 34776@debbugs.gnu.org
Subject: bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 00:29:13 -0700 [thread overview]
Message-ID: <87tvf6gvxy.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <871s3jeh8m.fsf@ericabrahamsen.net>
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@gnu.org>
>>> wrote:
>>> >>
>>> >> > And it can go to emacs-26 since it's a doc fix.
>>> >>
>>> >> The RC said Emacs 26.2 was to be released March 27...
>>> >> Part of making a release is for people to stop changing that
>>> branch.
>>> >
>>> > Unfortunately, that ship has sailed, since within an hour of RC
>>> > release a new commit was pushed to the release branch, and another
>>> one
>>> > a week later, without asking. So now the RC tarball will not be able
>>> > to be renamed anyway, and the rationale for withholding doc changes
>>> is
>>> > null and void.
>>> >
>>> > "Best laid plans" and all that.
>>>
>>> This sounds like a job for a git hook. I pay fairly close attention to
>>> emacs.devel for someone who isn't an Emacs dev, and apparently I
>>> missed
>>> this billboard.
>>
>> Not sure which billboard jou think you missed, but in general, I don't
>> see here any problem for which a commit hook would be a good solution.
>> The existing hooks are already annoying enough, and are too easy to
>> bypass to be reliable.
>
> What I meant was: if 200 people have the ability to push to the repo,
> but 50 of them aren't checking the mailing lists regularly, then you
> call a halt to an RC, that's 50 people who don't know they shouldn't
> push. It seems like a lot more work to chase after those 50 than to
> close the gate and reject pushes to that particular release.
I keep hitting C-c C-s (message-send) instead of C-x C-s (which would
save a draft), which I hope will explain my slightly rude tone here.
next prev parent reply other threads:[~2019-04-10 7:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 23:05 bug#34776: 27.0.50; Some questions about choose-completion-string-functions Eric Abrahamsen
[not found] ` <handler.34776.B.155191354931988.ack@debbugs.gnu.org>
2019-03-09 0:05 ` bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions) Eric Abrahamsen
2019-03-09 2:07 ` Glenn Morris
2019-03-13 16:51 ` Eric Abrahamsen
2019-04-10 0:03 ` Noam Postavsky
2019-04-10 3:16 ` Eric Abrahamsen
2019-04-10 3:29 ` Glenn Morris
2019-04-10 4:33 ` Eli Zaretskii
2019-04-10 6:35 ` Eric Abrahamsen
2019-04-10 7:01 ` Eli Zaretskii
2019-04-10 7:22 ` Eric Abrahamsen
2019-04-10 7:29 ` Eric Abrahamsen [this message]
2019-04-10 8:24 ` Eli Zaretskii
2019-04-10 8:05 ` Andreas Schwab
2019-04-10 8:22 ` Eli Zaretskii
2019-04-10 8:39 ` Andreas Schwab
2019-04-10 8:48 ` Eli Zaretskii
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=87tvf6gvxy.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=34776@debbugs.gnu.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).