Redundant distro branches
Daniel van Vugt
daniel.van.vugt at canonical.com
Wed Aug 26 01:50:56 UTC 2015
Wait a sec, is there really "going to be trouble"?
I am reminded that the landing on the train branch (lp:mir/ubuntu) is
always the _last_ thing to happen by far. lp:ubuntu/mir and
lp:ubuntu/wily-proposed/mir as well as the archive itself with shiny new
debs all get updated around a DAY earlier than the final landing to the
dummy branch (lp:mir/ubuntu) happens. It's annoyingly delayed, so that's
hard to forget.
Therefore, I doubt that using lp:ubuntu/something for the train to
monitor would cause trouble at all. Worst case is that it tries to land
the same branch twice. And we all know from previous experience that bzr
blindly succeeds and shows no diff landing any branch multiple times. I
think it would just work.
On 24/08/15 17:34, Stephen M. Webb wrote:
> On Mon, Aug 24, 2015 at 4:17 AM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> I'm kind of saying we should stop using:
>> lp:mir/ubuntu
>> and instead use:
>> lp:ubuntu/mir
>>
>> However that's not quite correct. You should target proposed first, so
>> actually we would target:
>> lp:ubuntu/wily-proposed/mir
>
> 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.
>
More information about the Mir-devel
mailing list