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