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
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
