OK, so the redundant distro branches have a reason: The train. Although
we could improve that slightly by renaming it to something train related
instead of the misleading lp:mir/ubuntu. But there's a better option
again...
Another apparently unnecessary part of the process is the merge proposal
itself. Why must we propose 30-50Kloc to the aforementioned redundant
branch for review at all? Hardly anyone looks at it. Why not just change
the train bot to look at:
lp:mir/0.16 (or whatever your next release is)
Or if you don't want to reconfigure the bot each time, use a dummy
series (like our current "ubuntu" series):
lp:mir/train-me-up-baby
which can then share the same physical branch as the next release series
like lp:mir/0.16
That way we can skip the whole massive proposal part and skip
lp:mir/ubuntu too.
In fact we could do that right now without any bot changes. Just point
lp:mir/ubuntu (where "ubuntu" means "train") to the same branch as
lp:mir/0.16 (when it exists). No MP required to do a release then.
On 24/08/15 17:54, Alan Griffiths wrote:
On 24/08/15 10:34, Stephen M. Webb wrote:
The problem is the dataflow.
The ci-train assumes an "upstream" repo (here, it's lp:mir/ubuntu)
into which it merges the target branches. It builds source debs,
which then get uploaded to the -proposed pocket of the archive, which
then migrates into the main (or -release) pocket of the archive and
gets imported into the lp:ubuntu/mir repo. If you point the ci-train
to merge target bracnhes directly into the Ubuntu archive, there's
going to be trouble.
The problem is that we've conflated the "Mir development" project and
the "Mir Ubuntu distro" project.
We address the requirements of both in the same project and that leads
to some confusion.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
