QtMir branching strategy

[Daniel van Vugt]

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).


On 07/08/15 23:37, Gerry Boland wrote:
> 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
>
>
>