[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging release branch
From: |
Eli Zaretskii |
Subject: |
Re: Merging release branch |
Date: |
Sat, 30 Oct 2021 15:48:31 +0300 |
> 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.
- Re: Merging release branch, (continued)
- Re: Merging release branch, Eli Zaretskii, 2021/10/29
- Re: Merging release branch, Lars Ingebrigtsen, 2021/10/30
- Re: Merging release branch, Eli Zaretskii, 2021/10/30
- Re: Merging release branch, Dmitry Gutov, 2021/10/30
- Re: Merging release branch, Eli Zaretskii, 2021/10/30
- Re: Merging release branch, Lars Ingebrigtsen, 2021/10/30
- Re: Merging release branch,
Eli Zaretskii <=
- Re: Merging release branch, Stefan Monnier, 2021/10/29
- Re: Merging release branch, Lars Ingebrigtsen, 2021/10/29
- Re: Merging release branch, Stefan Monnier, 2021/10/29
- Re: Merging release branch, David Engster, 2021/10/29
Re: Merging release branch, dick, 2021/10/29