[Development] Proposal: Eliminate soft branching phase from release process

[Kari Oikarinen]

On 12.10.2019 14.14, Oswald Buddenhagen wrote:
 > On Fri, Oct 11, 2019 at 12:04:20PM +0000, Kari Oikarinen wrote:
 >> I want to propose eliminating soft branching phase and instead use the
 >> creation of the branch as a cut-off for feature freeze (or bug fixes
 >> for a patch release).
 >>
 > (facepalm)
 >
 > but in case you actually tried to do your homework first ... well i'm
 > failing to find the old mails myself. something is rather b0rked with
 > the mail archive indexing; google and duckduckgo produce mostly hits to
 > the mbox files.

I did try to see if there was something about the reasons and asked
around a little. Thanks for bringing up original rationale.

 >
 >> As far as I can tell, the major motivation for providing this week of
 >> soft branching is to allow people to finish their last changes without
 >> needing to retarget the change to a new branch.
 >>
 > no, it's not.
 > the reason is that the huge CI delay makes it impractical to know
 > whether a change will still land in time for branch creation. also,
 > people just don't pay attention to the branching announcements in real
 > time.
 > so the alternatives to soft branching are a) restricting the source
 > branch before branching (which is obviously counterproductive) or b)
 > accepting the need for a significant number of cherry-picks (which are a
 > hassle to make, and an annoyance in the resulting git history).

What I'm thinking of is on the b) side of things. But I'm not sure why
the amount of cherry-picks would be a "significant number"?

When branching out a minor branch, new features that miss the
branching deadline miss the feature freeze. They don't need to be
cherry-picked. Wouldn't the category of bug fixes that are not
appropriate to the older stable branch but should happen in a feature
freezed branch be pretty narrow as well?

When branching out a release branch, only fixes to release blockers
should be cherry-picked. Everything else also missed a deadline and
appropriately belongs to the next release.

The window of time there is to make these mistakes varies, since it
starts from the branching happening and ends when there is somebody in
an open review that realizes the change should target the newly
created branch instead. That should be pretty short for people that
regularly read the development list, which of course isn't everyone.

The combination of restrictions in categories and time means that it
seems to me there shouldn't be that many commits to cherry-pick. What
type of commits that would need that handling do you expect a lot of?

 >
 >> Currently there is a bit of uncertainty about when exactly the
 >> downmerges happen,
 >>
 > yes, and that's entirely fine. the whole *point* of the process is to
 > make it irrelevant when it happens. if you rely on the time of the
 > downmerge but are not a release manager, you're doing it wrong.

It's not irrelevant! People who target the newly created branch should
not wait until the last minute to retarget and thus the exact point in
time does not matter to them.

But anyone who wants to *actually* target the old branch needs to wait
for the downmerge to pass. In effect the week of soft branching means
that the old branch is temporarily closed, because the changes staged
to it actually go to the newly created branch. The problem is that to
know whether that is the case you need to either read Jani's mails or
check the history for the downmerge. (And even if you did check, are
you sure it's final?)

 >
 >> since it requires not only someone to do it, but
 >> also CI not being active in the target branch. That's a requirement
 >> because downmerges (if they have no conflicts) are pushed directly to
 >> the repositories instead of going through regular CI. Eliminating them
 >> also eliminates this irregularity.
 >
 >> It hasn't been a big problem,
 >>
 > yes, exactly.
 >
 > but if you wanted to get rid of the direct pushes, the forward merge bot
 > (which is rather automated at that point, unlike back in the day) could
 > be easily extended to push and stage the downmerges as well.

Worth thinking about. But I'd probably lean towards continuing as
before if this proposal isn't accepted. Because they aren't a big
problem. I just thought getting rid of them would be a bonus.

-- 
Kari