[Development] Proposal: Eliminate soft branching phase from release process
kari.oikarinen at qt.io
Fri Oct 11 14:04:20 CEST 2019
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). Frederik already alluded that there has been
some discussion about making this change in the email about the final
downmerge to 5.13.2.
Right now a week before feature freeze the new branch is created and
the release manager sends a heads-up mail that tells people to finish
their changes within a week or retarget them to the new branch. Then
after the week is up the original branch is merged into the new
branch. This is called a "downmerge", since it is in the opposite
direction compared to the usual merges that go "up" to newer releases.
Once the downmerge is done, branching is considered complete and
feature freeze is in effect.
Similar week of soft branching is also involved when patch level
branches are created.
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. Retargeting of a large
number of changes would also have provided a large amount of work to
Gerrit admins, since on our old Gerrit retargeting the change needed
admin rights. And of course admin response time would have served as a
bottleneck to work.
Nowadays everyone can however move their own changes over to a new
branch. So as our tools have improved, I see a chance to simplify our
processes as well.
So instead of the soft branching process I propose the following:
- A week before feature freeze date release manager sends a reminder
email about it. This provides the same useful warning as the
initiation of soft branching has so far.
- On feature freeze day release team creates the new branch. They send
an email to development list informing people about the feature
freeze being in effect.
- If your change did not make it into dev before the new branch was
created, it did not make the feature freeze cut. If it is a bug fix
that should go to the next release still, you need to move it to the
new branch. If the change happened to be integrated after branch
creation but before you noticed, you need to cherry-pick it to the
new branch. But that should hopefully be an exception.
- There are no more downmerges. All merges happen in the same
direction. Hopefully that makes how they happen easier to
The same approach should be used for patch level branches as well.
Currently there is a bit of uncertainty about when exactly the
downmerges happen, 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, but
these commits have no corresponding Gerrit changes, which has confused
people when they can't actually find the review because there wasn't
one. It can also result in broken state of code, although only rarely.
By getting rid of downmerges we eliminate the vast majority of direct
pushes (and all regularly done ones).
Since branches can be created without waiting for idle CI, the timing
of feature freeze coming into effect could become better known in
advance. This helps in avoiding confusion about whether it's in effect
If this is approved, I promise to edit QUIP-11  to match.
: https://codereview.qt-project.org/c/meta/quips/+/228450 -
Hopefully it will be merged at some point...
More information about the Development