QtMir branching strategy

[Gerry Boland]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150807/d90235dd/attachment.pgp>