Subject: Redundant distro branches

From: Daniel van Vugt <[email-masked]>
Date: Mon, 24 Aug 2015 15:45:24 +0800

We've been using this as our distro branch for a while, but actually the 
distro does not use it:
    https://code.launchpad.net/~mir-team/mir/ubuntu

Why don't we just target future releases to the actual ubuntu (proposed) 
branch instead?
    https://code.launchpad.net/ubuntu/+source/mir

Presently I'm guessing most of ~mir-team can't write to those branches, 
but that's OK... we probably only need to be able to propose to them. No 
write access required.

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 24 Aug 2015 09:04:22 +0100

On 24/08/15 08:45, Daniel van Vugt wrote:
> We've been using this as our distro branch for a while, but actually
> the distro does not use it:
> Why don't we just target future releases to the actual ubuntu
> (proposed) branch instead?
> Presently I'm guessing most of ~mir-team can't write to those
> branches, but that's OK... we probably only need to be able to propose
> to them. No write access required.
>

I've never been comfortable with the use of branches.

It makes sense for the mir team to manage the development branch
(lp:mir) and release branches (lp:mir/0.15, lp:mir/0.14 etc.).

The distro branches, however, for vivid, wily and vivid-phablet-overlay
(which is like a distro as far managing our releases goes) as you say
are really ought to be owned by the distro.

If for operational reasons we need to provide a distro specific URL the
most we should be doing is maintaining an alias to a corresponding
release branch. (But I don't see why this would be needed.)

I think I'm agreeing with you.

Alan

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 24 Aug 2015 16:17:22 +0800

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

I can only imagine we're using lp:mir/ubuntu for one of two reasons:
    * Historical mistakes and nobody noticed; or
    * The "train" needs a separate branch.

If the latter is the reason then it would be helpful for us to at least 
clarify for our own benefit that:
    lp:mir/ubuntu
actually means:
    lp:mir/proposed-to-the-train

---

From: "Stephen M. Webb" <[email-masked]>
Date: Mon, 24 Aug 2015 05:34:50 -0400

>    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.

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 24 Aug 2015 10:54:00 +0100

> to merge target bracnhes directly into the Ubuntu archive, there's

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.

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 25 Aug 2015 09:37:14 +0800

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.

---

From: Alberto Aguirre <[email-masked]>
Date: Mon, 24 Aug 2015 22:13:55 -0500

The CI train also requires a merge proposal.

> On Aug 24, 2015, at 8:37 PM, Daniel van Vugt <[email-masked]> wrote:
> 
> 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:
> 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.
> 
> 
> -- 
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 25 Aug 2015 11:15:21 +0800

Thanks. I feared that, and was waiting for someone like you to confirm it.

So Mir's ubuntu branch messiness is all to support the train...

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 25 Aug 2015 08:50:52 +0100

> The CI train also requires a merge proposal.

How does it handle projects that are hosted outside of launchpad?

---

From: Michał Sawicz <[email-masked]>
Date: Tue, 25 Aug 2015 16:17:29 +0200

> The CI train also requires a merge proposal.

Not necessarily true, you can just build a source package locally and
upload it to the train PPA. It's just more manual labour this way. And
that's how it deals with projects outside of LP.

-- 
Michał Sawicz <[email-masked]>
Canonical Ltd.

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 25 Aug 2015 15:50:28 +0100

> that's how it deals with projects outside of LP.

That sounds like something that could easily be automated to the level
that the "manual labour" is clicking a "push release to wily train"
button. Or am I missing something?

---

From: Alberto Aguirre <[email-masked]>
Date: Tue, 25 Aug 2015 10:14:22 -0500

That's what the merge proposal is used for! :) ci-train takes the MP,
creates a source package from it, uploads it to the assigned PPA.

On Tue, Aug 25, 2015 at 9:50 AM, Alan Griffiths <
[email-masked]> wrote:

> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Aug 2015 09:50:56 +0800

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.

---

From: Michał Sawicz <[email-masked]>
Date: Wed, 26 Aug 2015 12:03:48 +0200

> dummy branch (lp:mir/ubuntu) happens. It's annoyingly delayed, so that's

Hmm? Not sure what changed since I was last here, but that shouldn't be
the case. The target branch of the landed MP(s) (lp:mir/ubuntu?) should
be pushed to as soon as the packages migrate to the release pocket.
That's the same time when lp:ubuntu/mir is updated, with
lp:ubuntu/wily-proposed/mir being updated as soon as the silo is
published and the packages pushed to the proposed pocket.

> think it would just work.

I think you're missing one thing here: lp:ubuntu/mir does not get merged
into. Launchpad just takes the source package as uploaded to the archive
and imports the changes as a new commit. While the contents might be the
same, it will be a different commit.

If you really don't want to maintain a Ubuntu packaging branch (which
lp:mir/ubuntu really is), you'll just need to build the source packages
by hand and ask the train staff to upload them to your silos.
-- 
Michał Sawicz <[email-masked]>
Canonical Ltd.

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 27 Aug 2015 09:56:00 +0800

There's no maintaining that needs to be saved, only potential confusion. 
I'm just trying to make the process a bit simpler and clearer wherever 
possible.

Admittedly I chose the name lp:mir/ubuntu a while back and now it's 
apparent there's a potential for confusion in that name it's reasonable 
to want to clarify it for future  contributors. lp:mir/ubuntu would be 
better named if it had "train" in its name. And even better again if it 
didn't have it's own pointlessly unique history (different to 
lp:ubuntu/mir), so that's another thing we could improve...

I'm not content with keeping the whole train process as complicated as 
it is forever. If we can pick away at it with small improvements at 
least, that's some progress.