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