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

[Liang Qi]

We are using soft branching phase for two categories:

1. feature frozen or minor branch, like dev to 5.14, many new changes are targeting 5.14 release, but happened in dev branch, and not easy to be integrated or verified soon. the one week soft branching phase could help bit here.

2. patch releases, 1st one and others, for the first one, like 5.14.0 perhaps similar story like above. Anyway, for the patch releases, if the changes missed this release, but still could happen in next. So I think it’s better to remove the one week soft branching phase.

And for the 1st case, if we want to the "soft branching phase”, we could also find some solution for it, perhaps like some feature branches and pre-checking things.

Provisioning changes and coin update(perhaps other hardware or IT issues) also could affect the whole process. A better plan, not having too many things in the short one week for feature frozen period, is perhaps needed.

—Liang

> On 11 Oct 2019, at 14:16, Jani Heikkinen <jani.heikkinen at qt.io> wrote:
> 
> +1
> 
> This change might also speed up patch level releases a bit
> 
> br,
> Jani
> 
> ________________________________________
> From: Development <development-bounces at qt-project.org> on behalf of Kari Oikarinen <kari.oikarinen at qt.io>
> Sent: Friday, October 11, 2019 3:04 PM
> To: Qt development mailing list
> Subject: [Development] Proposal: Eliminate soft branching phase from release    process
> 
> 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
>   understand.
> 
> 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
> or not.
> 
> If this is approved, I promise to edit QUIP-11 [1] to match.
> 
> [1]: https://codereview.qt-project.org/c/meta/quips/+/228450 -
>      Hopefully it will be merged at some point...
> 
> --
> Kari
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development