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