Subject: QtMir branching strategy

From: Gerry Boland <[email-masked]>
Date: Fri, 07 Aug 2015 16:37:31 +0100

Hey,
so getting anything landed this past month has been a right pain.

If Mir has problems, QtMir is totally blocked from landing any code
until they're resolved. If QA is backed up, we can't land anything.

And right now, the GCC5.0 transition has the train blocked for Wily.
That's a much more unusual occurrence, but still I'm loosing patience
with this system.

I want to move QtMir to the more traditional branching scheme of:
- having lp:qtmir be development trunk, landing code when reviewed by
team member.
- branch off lp:qtmir for each release version, which then goes through
the CI train.

This is what the Mir and UITK teams do, and considering the complexity
of their software, it works well.

This would mean we can keep developing and not worry about branches
piling up, waiting to land.

It also means in future, if we need to have separate release branches
for vivid+overlay and wily, we don't have much additional work do to.

I also like being able to point people to lp:qtmir and call it "trunk",
as opposed to a list of branches which represent the current state of
development.

Opposing argument is that the CI train system forces us to keep quality
high. I don't see any reason why changing our branching model would
cause quality of releases to degrade. One could argue that it means that
the quality of each intermediary code change could drop, but I'm
prepared to take this theoretical risk to gain a definite improvement in
development speed and making releases easier.

Problems should we decide to change our branching model:

1. qtmir depends on unity-api, so would need to maintain a
unity-api/qtmir-devel branch along side, or else keep doing the separate
branches per change as per usual.

2. all unity8 changes due to qtmir would still need to live in separate
branches, as long as the unity8 team keeps the current system.

Are there objections or opinions about this?
-G

---

From: Alan Griffiths <[email-masked]>
Date: Fri, 07 Aug 2015 18:00:17 +0100

> development speed and making releases easier.

I guess it is a matter of discipline, but IMO the current state of
development should kept in a state that can be released. To me that
seems easier if there's an integration branch/trunk representing
completed development, not a collection of merge proposals that need to
be consolidated at release time.

Merging work when completed also shortens the feedback cycle between
doing the work and detecting conflicts or other incompatibilities with
other changes.

> Are there objections or opinions about this?

I approve it.

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 10 Aug 2015 10:07:29 +0800

Sounds good. In fact I made the mistake of thinking it was lp:qtmir already.

Also, if by 'release branches' you mean Ubuntu distro branches, then 
they already exist under the Ubuntu project:
    https://code.launchpad.net/ubuntu/+source/qtmir
You theoretically should not need one in lp:qtmir/* except to support 
non-standard processes (those LP wasn't designed for).

Makes me wonder why we maintain pseudo-distro-branches at all... (e.g. 
we use lp:mir/ubuntu, but distro actually uses the more correct 
lp:ubuntu/mir, and they are different).