From: Eli Zaretskii <eliz@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: rgm@gnu.org, stefan@marxist.se, monnier@iro.umontreal.ca,
emacs-devel@gnu.org
Subject: Re: Merging release branch
Date: Sat, 30 Oct 2021 15:48:31 +0300 [thread overview]
Message-ID: <831r42ptk0.fsf@gnu.org> (raw)
In-Reply-To: <87mtmqr8wn.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Oct 2021 14:31:36 +0200)
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca, rgm@gnu.org, stefan@marxist.se,
> emacs-devel@gnu.org
> Date: Sat, 30 Oct 2021 14:31:36 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> The people who commit things to master would also be tasked with
> >> deciding whether to cherry-pick things for the release branch.
> >
> > That assumes they will want to, and will do a good job.
>
> That's an assumption that doesn't change -- we assume that now, and we
> continue to assume so in the future.
No, until now committers didn't have to merge to master, they just
committed to a single branch.
> >> Speaking for myself, a cherry-picking work flow would be less work, not
> >> more work in general, because I normally use an Emacs from the master
> >> branch.
> >
> > Then it's good for you, but not for me: when a release is in progress,
> > I work mainly on the release branch.
>
> And you can continue to do so -- and cherry-pick commits to master.
That's a disadvantage, because Git will not help us track which
changes from the branch are on master (and vice versa).
> > And of course, cherry-picking doesn't remove merge conflicts, they
> > will still need to be resolved.
>
> So that's neither more than less work than the merge based work flow --
> but with the advantage that you're resolving one pick at a time instead
> of the more overwhelming thing that can happen when merging and you get
> conflicts from several commits at once.
Conflicts are generally rare with Git, though.
> > We've been using the current workflow for years without any major
> > problems. Changing that now radically doesn't make sense to me. It
> > will most probably need several procedures to be modified that were
> > stable for several releases, and I don't see the gains which would
> > justify that. We have enough real work on our hands. So please let's
> > not do that.
>
> What's changed is that Glenn is (understandably) no longer willing to do
> the merges, so something has to change. (Unless somebody else picks up
> the slack, and we can continue as before.)
We haven't even tried to find a new volunteer yet. You suggest that
we give up before we even try.
next prev parent reply other threads:[~2021-10-30 12:48 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-29 16:35 Merging release branch Glenn Morris
2021-10-29 16:42 ` Lars Ingebrigtsen
2021-10-29 17:01 ` Stefan Kangas
2021-10-29 18:10 ` Stefan Monnier
2021-10-29 18:26 ` Lars Ingebrigtsen
2021-10-29 18:52 ` Lars Ingebrigtsen
2021-10-29 19:55 ` Daniel Martín
2021-10-30 11:42 ` Lars Ingebrigtsen
2021-10-30 13:42 ` Daniel Martín
2021-10-30 20:32 ` Tassilo Horn
2021-10-29 19:58 ` Eli Zaretskii
2021-10-30 11:51 ` Lars Ingebrigtsen
2021-10-30 12:11 ` Eli Zaretskii
2021-10-30 12:30 ` Dmitry Gutov
2021-10-30 12:32 ` Eli Zaretskii
2021-10-30 13:34 ` dick
2021-10-31 11:38 ` Dmitry Gutov
2021-10-31 13:03 ` Eli Zaretskii
2021-10-30 16:33 ` Eli Zaretskii
2021-10-30 21:36 ` Dmitry Gutov
2021-10-31 7:19 ` Eli Zaretskii
2021-10-30 23:14 ` Gregory Heytings
2021-10-30 23:17 ` Dmitry Gutov
2021-10-31 7:20 ` Eli Zaretskii
2021-10-31 8:13 ` Gregory Heytings
2021-10-31 11:40 ` Dmitry Gutov
2021-10-31 12:58 ` Gregory Heytings
2021-10-31 21:59 ` Dmitry Gutov
2021-10-31 14:46 ` Lars Ingebrigtsen
2021-10-31 15:12 ` Eli Zaretskii
2021-10-31 15:15 ` Lars Ingebrigtsen
2021-10-31 16:02 ` Dealing with merge noise (was: Merging release branch) Kévin Le Gouguec
2021-10-31 18:19 ` Stefan Kangas
2021-10-31 18:31 ` Eli Zaretskii
2021-10-31 22:00 ` Merging release branch Dmitry Gutov
2021-10-30 12:31 ` Lars Ingebrigtsen
2021-10-30 12:48 ` Eli Zaretskii [this message]
2021-10-29 19:00 ` Stefan Monnier
2021-10-29 19:05 ` Lars Ingebrigtsen
2021-10-29 19:17 ` Stefan Monnier
2021-10-29 20:29 ` David Engster
2021-10-29 17:08 ` dick
2021-11-06 9:28 ` Eli Zaretskii
2021-11-06 10:53 ` Stefan Kangas
2021-11-06 16:14 ` Glenn Morris
2021-11-06 16:11 ` Glenn Morris
2021-11-06 17:19 ` 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=831r42ptk0.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=rgm@gnu.org \
--cc=stefan@marxist.se \
/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.