From: Eli Zaretskii <eliz@gnu.org>
To: emacs-devel@gnu.org, Noam Postavsky <npostavs@gmail.com>,
Emacs developers <emacs-devel@gnu.org>
Cc: Eric Abrahamsen <eric@ericabrahamsen.net>
Subject: Re: Branch freezing for release (WAS: bug#34776)
Date: Wed, 10 Apr 2019 12:21:05 +0300 [thread overview]
Message-ID: <4C62647A-5A71-4C82-9D37-ED933023AFC0@gnu.org> (raw)
In-Reply-To: <87tvf69r16.fsf_-_@gmail.com>
On April 10, 2019 11:57:09 AM GMT+03:00, Noam Postavsky <npostavs@gmail.com> wrote:
> >>>>>> 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 [...]
>
> >>>> 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.
>
> Git supports server-side hooks which can't be bypassed. If I read
> githooks(5) correctly, then putting an update hook on the server with
> contents:
>
> if [ "$1" = emacs-26 ]; then
> echo "Branch $1 is frozen"
> exit 1
> fi
>
> would do it. There would still be some additional complication with
> letting in the commit for the RC itself though. Andreas' suggestion
> to
> just let unexpected commits miss being in the release seems simpler.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34776#61
We don't have access to the server, so doing this would be a significant complication, even if we ignore the annoyance of a rejected commit and a potential for failing to push if one doesn't watch the messages closely enough (actually happened to me at least once).
> >> 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.
> >
> > There's no need to check the mailing list, this stuff is in
> > CONTRIBUTE. That's why I never called for any halts.
>
> CONTRIBUTE says:
>
> Doc fixes are always considered "safe" -- even when a release branch
> is
> in feature freeze, it can still receive doc fixes.
>
> I don't see anything there about not pushing after an RC is made (and
> how would someone know about the RC without checking the mailing
> list?)
There's no need to say anything else, since an RC should be tarred after all its changes are pushed and tagged. That didn't happen this time by omission. We all make mistakes at times.
next prev parent reply other threads:[~2019-04-10 9:21 UTC|newest]
Thread overview: 45+ 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
2019-04-10 8:24 ` Eli Zaretskii
2019-04-10 8:57 ` Branch freezing for release (WAS: bug#34776) Noam Postavsky
2019-04-10 9:21 ` Eli Zaretskii [this message]
2019-04-10 16:16 ` Noam Postavsky
2019-04-10 16:40 ` Eli Zaretskii
2019-04-10 16:59 ` Branch freezing for release Basil L. Contovounesios
2019-04-10 17:12 ` Eli Zaretskii
2019-04-10 17:39 ` Basil L. Contovounesios
2019-04-10 18:31 ` Eli Zaretskii
2019-04-11 14:02 ` Basil L. Contovounesios
2019-04-22 13:03 ` Basil L. Contovounesios
2019-04-22 13:14 ` Eli Zaretskii
2019-04-22 15:18 ` Basil L. Contovounesios
2019-04-10 17:56 ` Stefan Monnier
2019-04-10 18:26 ` Eli Zaretskii
2019-04-10 18:54 ` Stefan Monnier
2019-04-10 19:19 ` Eli Zaretskii
2019-04-10 20:16 ` Dmitry Gutov
2019-04-11 0:12 ` Noam Postavsky
2019-04-11 13:52 ` Eli Zaretskii
2019-04-12 1:03 ` Noam Postavsky
2019-04-12 7:04 ` Eli Zaretskii
2019-04-12 10:18 ` Noam Postavsky
2019-04-12 12:23 ` Stefan Monnier
2019-04-12 12:24 ` Eli Zaretskii
2019-04-12 14:14 ` Dmitry Gutov
2019-04-10 13:14 ` Stefan Monnier
2019-04-10 13:47 ` Andreas Schwab
2019-04-10 15:03 ` Eli Zaretskii
2019-04-10 8:05 ` bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions) 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C62647A-5A71-4C82-9D37-ED933023AFC0@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=eric@ericabrahamsen.net \
--cc=npostavs@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.