Redundant distro branches
Daniel van Vugt
daniel.van.vugt at canonical.com
Tue Aug 25 01:37:14 UTC 2015
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.
>
More information about the Mir-devel
mailing list