[Releasing] rethinking branching again
oswald.buddenhagen at digia.com
Sun Aug 10 19:40:40 CEST 2014
so, the 5.4 branching went technically (almost) as planned.
what went wrong again is of course ... ehm ... let's call it "wiggle
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
- 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?
More information about the Releasing