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@qt-project.org https://lists.qt-project.org/listinfo/development