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

[Oswald Buddenhagen]

On Mon, Oct 14, 2019 at 01:40:48PM +0000, Kari Oikarinen wrote:
>On 12.10.2019 14.14, Oswald Buddenhagen wrote:
> > On Fri, Oct 11, 2019 at 12:04:20PM +0000, Kari Oikarinen wrote:
> >> 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"?
>
it's more than a handful, so it's significant.
that's because every cherry-pick potentially causes CI load (if it 
doesn't end up in a bigger CI batch), requires the usual repetitive 
re-staging ritual, and then causes confusion when someone tries to 
actually make sense of the history.

>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.
>
in practice, there are always last-minute additions, usually with 
pre-approval for going into the next release.

>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?
>
bugfixes to new features are actually rather common. it's what this 
"stabilization" thing is all about.

>But anyone who wants to *actually* target the old branch needs to wait
>for the downmerge to pass.
>
as you found out yourself, that's a non-usecase.

the gist is that this somewhat complicated downmerge process exists for 
good reasons. it shifts the "logistical" load of dealing with the 
branching from every contributor to the few people involved in the 
branch management.

history (now found via browsing archives; it appears impossible to 
google that message without putting the exact subject in quotes):
https://lists.qt-project.org/pipermail/releasing/2014-August/001804.html
there appears to be no other public list activity related to this. 
apparently, everything happened on irc.

the previous installment of evolving policy was here:
https://lists.qt-project.org/pipermail/releasing/2014-February/001618.html
(that's essentially what you want to go back to).
as you can see from the dates, it took us a single feature release to 
conclude that another change was necessary.