From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Branch freezing for release
Date: Wed, 10 Apr 2019 18:03:46 +0300 [thread overview]
Message-ID: <83zhox6gx9.fsf@gnu.org> (raw)
In-Reply-To: <jwv7ec2uhwm.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Wed, 10 Apr 2019 09:14:06 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 10 Apr 2019 09:14:06 -0400
>
> FWIW, that's part of the reason why I suggested that we make
> a emacs-26.2 branch once we start entering the phase where we should not
> push any change unless explicitly allowed by the maintainer. This way
> people can keep pushing random bug fixes to emacs-26, unaware that
> an emacs-26.2 was created.
Unless the hypothetical emacs-26.2 branch is local, why would people
be unaware of its creation? Git happily announces its creation and
each of its updates on every fetch/pull.
> It's also useful for bug fixes which we'd want to have in a hypothetical
> 26.3, so they don't get lost in master. It makes the rules simple:
>
> - master: always open for business.
> - emacs-NN: bug-fixes only (merged back to master every once in a while)
> - emacs-NN.MM: never touch unless specifically authorized to do so.
I don't see this as a simplification, I see this as a complication:
one more branch to track, to describe in CONTRIBUTE, to educate people
about, to avoid mixing with others, etc.
> Look ma! No need to follow emacs-devel to know in which phase we are!
There's no need to follow emacs-devel now, either. The rules are laid
out in CONTRIBUTE, and once each RC will have its modifications pushed
and tagged, the problem which led to this particular bikeshedding
should not happen again. IOW, this is a normal process of learning
how to release Emacs cleanly.
next prev parent reply other threads:[~2019-04-10 15:03 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
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 [this message]
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=83zhox6gx9.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.