From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Branch freezing for release (WAS: bug#34776) Date: Wed, 10 Apr 2019 12:21:05 +0300 Message-ID: <4C62647A-5A71-4C82-9D37-ED933023AFC0@gnu.org> References: <871s3jeh8m.fsf@ericabrahamsen.net> <87zhq4zzcz.fsf@ericabrahamsen.net> <871s3a90qo.fsf@ericabrahamsen.net> <87imvmbube.fsf@gmail.com> <87mukyiczg.fsf@ericabrahamsen.net> <877ec2iau1.fsf@ericabrahamsen.net> <4CAA6D9F-0402-489C-8DD1-CE2ADBAA42C9@gnu.org> <87tvf69r16.fsf_-_@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="72153"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: K-9 Mail for Android Cc: Eric Abrahamsen To: emacs-devel@gnu.org, Noam Postavsky , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 10 11:21:49 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hE9QT-000IdM-1T for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 11:21:49 +0200 Original-Received: from localhost ([127.0.0.1]:56312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hE9QR-0007B2-Vn for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 05:21:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hE9Pq-0007Av-59 for emacs-devel@gnu.org; Wed, 10 Apr 2019 05:21:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hE9Pp-0003pI-0S; Wed, 10 Apr 2019 05:21:09 -0400 Original-Received: from [109.253.166.16] (port=38121 helo=[10.131.121.239]) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1hE9Po-0007Bl-8U; Wed, 10 Apr 2019 05:21:08 -0400 In-Reply-To: <87tvf69r16.fsf_-_@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235194 Archived-At: On April 10, 2019 11:57:09 AM GMT+03:00, Noam Postavsky wrote: > >>>>>> The RC said Emacs 26=2E2 was to be released March 27=2E=2E=2E Pa= rt of > >>>>>> making a release is for people to stop changing that branch=2E > >>>>> > >>>>> Unfortunately, that ship has sailed, since within an hour of RC > >>>>> release a new commit was pushed to the release branch [=2E=2E=2E] >=20 > >>>> This sounds like a job for a git hook=2E I pay fairly close > >>>> attention to emacs=2Edevel for someone who isn't an Emacs dev, and > >>>> apparently I missed this billboard=2E > >>> > >>> 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=2E The existing hooks are already annoying enough, and are > >>> too easy to bypass to be reliable=2E >=20 > Git supports server-side hooks which can't be bypassed=2E If I read > githooks(5) correctly, then putting an update hook on the server with > contents: >=20 > if [ "$1" =3D emacs-26 ]; then > echo "Branch $1 is frozen" > exit 1 > fi >=20 > would do it=2E There would still be some additional complication with > letting in the commit for the RC itself though=2E Andreas' suggestion > to > just let unexpected commits miss being in the release seems simpler=2E >=20 > https://debbugs=2Egnu=2Eorg/cgi/bugreport=2Ecgi?bug=3D34776#61 We don't have access to the server, so doing this would be a significant c= omplication, even if we ignore the annoyance of a rejected commit and a pot= ential for failing to push if one doesn't watch the messages closely enough= (actually happened to me at least once)=2E > >> 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=2E It seems like a lot more work to chase after those 50 than to > >> close the gate and reject pushes to that particular release=2E > > > > There's no need to check the mailing list, this stuff is in > > CONTRIBUTE=2E That's why I never called for any halts=2E >=20 > CONTRIBUTE says: >=20 > Doc fixes are always considered "safe" -- even when a release branch > is > in feature freeze, it can still receive doc fixes=2E >=20 > 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 a= ll its changes are pushed and tagged=2E That didn't happen this time by om= ission=2E We all make mistakes at times=2E