all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Noam Postavsky <npostavs@gmail.com>
To: Emacs developers <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
Cc: Eric Abrahamsen <eric@ericabrahamsen.net>,
Subject: Branch freezing for release (WAS: bug#34776)
Date: Wed, 10 Apr 2019 04:57:09 -0400	[thread overview]
Message-ID: <87tvf69r16.fsf_-_@gmail.com> (raw)
In-Reply-To: <4CAA6D9F-0402-489C-8DD1-CE2ADBAA42C9@gnu.org> (Eli Zaretskii's message of "Wed, 10 Apr 2019 11:24:41 +0300")

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

>> 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?)



  reply	other threads:[~2019-04-10  8:57 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                       ` Noam Postavsky [this message]
2019-04-10  9:21                         ` Branch freezing for release (WAS: bug#34776) Eli Zaretskii
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=87tvf69r16.fsf_-_@gmail.com \
    --to=npostavs@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=eric@ericabrahamsen.net \
    /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.