Hi all,
I totally forgot Ossi's proposal to start using 'soft branching' scheme, see
attached mail.
We agreed with Ossi to use this scheme with 5.4.0. That's why '5.4.0' branch is
created already now & developers can start using it for changes targeted to
Qt5.4.0 release. We will do downmerge from '5.4' to '5.4.0' on Monday 10th
November (some time in the morning) so there should be enough time to finalize
ongoing changes in '5.4' and start using '5.4.0' for changes targeted to
Qt5.4.0 release. So no need to start re-targeting changes to '5.4.0' if you are
expecting it to land in '5.4' the next few days...
After Monday morning '5.4' branch will be for changes targeted to Qt5.4.1
release.
'5.4.0' branch is for changes targeted to Qt5.4.0 release. As I wrote, no any
nice to have's in '5.4.0'! Like earlier, only qt release team has staging
rights in '5.4.0' branch. We will monitor approved changes in that branch &
stage clear ones automatically. If there is some uncertainty with change we
will contact to owner to agree if change is critical enough to be taken in at
this point anymore.
Br,
Jani
From: Heikkinen Jani
Sent: 4. marraskuuta 2014 10:45
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: HEADS UP: Qt5.4.0 branching Monday 10th Nov
Importance: High
Hi,
We are planning to branch Qt5.4.0 from '5.4' Monday 10th November. It means:
- '5.4' branch will be temporarily locked 10th November 2014 07:00 CET
* We will wait ongoing integrations to succeed/fail before doing the branch.
* After that time any changes that are required for Qt 5.4.0 needs to be pushed
to the '5.4.0' branch. NOTE: No any nice to have's in '5.4.0', only real
showstoppers in there!
We will inform when '5.4.0' is available and when '5.4' is open again for
changes for Qt5.4.1
Br
Jani
--- Begin Message ---
so, the 5.4 branching went technically (almost) as planned.
what went wrong again is of course ... ehm ... let's call it "wiggle
room".
as i (as an executive force of RM) don't feel like dealing with these
issues each time, i'd like to propose yet another modification to the
branch creation process. the idea was brought up by olivier:
- the branch is created one week _before_ the feature freeze, from
whichever state dev is in
- at the announced date of the freeze, we do a downmerge dev -> new
branch, also from whichever state dev is in
this has the following features:
- as the branch exists early, people can start submitting their "must
have" changes there early. this is also the time to obtain freeze
excemptions for "epic" changes that are running late, and having them
retargeted.
- as the "branching window" is naturally long, there is almost no risk
that cherry-picking would be necessary due to somebody missing it
- therefore there is also no need for a lockdown on dev, which means
that nobody can complain about being held up by unrelated release work
- RM doesn't need to pay attention to any freeze excemption quibbles,
because people really have enough time to sort it out with their
reviewers and maintainers.
- the final downmerge is expected to be rather unproblematic (wholly
unlike the former dev -> stable downmerge), as the branch (and its
integration setup) was created only shortly before.
- of course this has the unfortunate effect that branching (RM task)
again involves a dev task (merging), but whatever.
in principle, that model seems applicable to release branch creation as
well, so we can already try it on 5.4.0 (possibly with a shorter window
than a week - maybe three days).
anything fundamentally wrong with the idea?
_______________________________________________
Releasing mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/releasing
--- End Message ---
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
