Subject: Care and feeding of downstreams

From: Daniel van Vugt <[email-masked]>
Date: Fri, 06 Mar 2015 17:55:01 +0800

Hi all,

The following branches are failing to build right now. Could the owners 
of the respective changes please look into the issues?

lp:qtmir/devel-mir-next
   kdub: Display class changes (still calling flip())
   racarr: keymap_changed()

lp:unity-system-compositor/devel-mir-next
   racarr: spinner/eglapp.c needs buffer stream (copy from lp:mir?)
   alan_g: mir/time/timer.h missing
   alan_g: FocusController changed

There may be more build failures hiding behind those ones...

- Daniel

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 06 Mar 2015 17:57:44 +0800

"failing to build against lp:mir" I mean.

---

From: Alan Griffiths <[email-masked]>
Date: Fri, 06 Mar 2015 10:04:46 +0000

> "failing to build against lp:mir" I mean.

Point taken.

We should automate this check.

>>    alan_g: mir/time/timer.h missing

OTOH I don't deserve credit for AlbertA's work.

---

From: Kevin DuBois <[email-masked]>
Date: Tue, 10 Mar 2015 16:59:48 -0400

As for the Display changes, the branch is/was here:
https://code.launchpad.net/~kdub/qtmir/display-groups

It seems sensible to me that the mir team should keep around a list (google
docs maybe?) of the branches that fix the downstreams. If in the review
process, we find that a change breaks the downstream, maybe we should wait
to land that branch until the downstreams have a fix. This would make it
easier for the release-designate come release time, as well as anyone
trying to tinker with the whole stack against lp:mir.

On Fri, Mar 6, 2015 at 5:04 AM, Alan Griffiths <[email-masked]
> wrote:

> --
> 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: Wed, 11 Mar 2015 09:37:11 +0800

~mir-team owns the */devel-mir-next branches AFAIK. So we can and should 
land changes to those directly without waiting or reviews (or external 
documents). It will then get reviewed by downstream when the downstream 
team wants to merge it to their trunk.

Failing to update */devel-mir-next just holds everyone else up (mir-team 
and downstreams). As we cannot do whole-stack testing with the latest code.

On 11/03/15 04:59, Kevin DuBois wrote:
> It seems sensible to me that the mir team should keep around a list
> (google docs maybe?) of the branches that fix the downstreams. If in the
> review process, we find that a change breaks the downstream, maybe we
> should wait to land that branch until the downstreams have a fix. This
> would make it easier for the release-designate come release time, as
> well as anyone trying to tinker with the whole stack against lp:mir.
>
> On Fri, Mar 6, 2015 at 5:04 AM, Alan Griffiths
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>