Subject: A new FTBFS every day

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Jun 2013 10:32:55 +0800

Martin,

Since we moved CI to saucy only, we keep landing code that fails to 
build on gcc-4.7 (raring) for various reasons.

I know we don't care about raring as much as saucy, but we do care about 
Mir being consumable in other distros. And that means broad-ish support 
for gcc versions.

Can we add raring CI support back in so these build problems get caught 
in time?

- Daniel

---

From: Thomi Richards <[email-masked]>
Date: Wed, 26 Jun 2013 14:49:04 +1200

Hi Daniel,

On Wed, Jun 26, 2013 at 2:32 PM, Daniel van Vugt <
[email-masked]> wrote:

>
> Can we add raring CI support back in so these build problems get caught in
> time?
>
>
I believe that's a question for me, and the answer is "yes, we can". Unless
there are any objections, I'll add raring as a CI platform tomorrow
(thereby giving the list 12 hours to object).

Cheers,

-- 
Thomi Richards
[email-masked]

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Jun 2013 10:50:20 +0800

I doubt people would object to increased automation, unless we start 
needing language features missing in gcc-4.7.

On 26/06/13 10:49, Thomi Richards wrote:
> Hi Daniel,
>
>
> On Wed, Jun 26, 2013 at 2:32 PM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>
>     Can we add raring CI support back in so these build problems get
>     caught in time?
>
>
> I believe that's a question for me, and the answer is "yes, we can".
> Unless there are any objections, I'll add raring as a CI platform
> tomorrow (thereby giving the list 12 hours to object).
>
>
> Cheers,
>
>
> --
> Thomi Richards
> [email-masked] <mailto:[email-masked]>

---

From: Robert Ancell <[email-masked]>
Date: Wed, 26 Jun 2013 16:22:40 +1200

I do disagree that increased automation is better. In this case our target
platform is GCC 4.8 and slowing down to fix bugs in GCC 4.7 isn't a
worthwhile use of time. I appreciate there might be cases where these are
genuine bugs that 4.8 is not detecting, but that seems more of a problem in
GCC than our code. Also, it seems highly likely for us to use a GCC 4.8
feature given we are already using modern C++ features.

--Robert

On Wed, Jun 26, 2013 at 2:50 PM, Daniel van Vugt <
[email-masked]> wrote:

>> <[email-masked] <mailto:daniel.van.vugt@**canonical.com<[email-masked]>
>> >>
>>
>> wrote:
>>
>>
>> [email-masked] <mailto:thomi.richards@**canonical.com<[email-masked]>
>> >
>>
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/mir-devel<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Jun 2013 13:49:14 +0800

Put it this way: I will waste more time waiting for builds on my saucy 
machines, than I spend fixing the raring build failures (so I can build 
on my faster raring machine).

And the fixes so far have been trivial. When they're not, I will 
reconsider where my effort goes.

On 26/06/13 12:22, Robert Ancell wrote:
> I do disagree that increased automation is better. In this case our
> target platform is GCC 4.8 and slowing down to fix bugs in GCC 4.7 isn't
> a worthwhile use of time. I appreciate there might be cases where these
> are genuine bugs that 4.8 is not detecting, but that seems more of a
> problem in GCC than our code. Also, it seems highly likely for us to use
> a GCC 4.8 feature given we are already using modern C++ features.
>
> --Robert
>
>
> On Wed, Jun 26, 2013 at 2:50 PM, Daniel van Vugt
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>         wrote:
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>
>     --
>     Mir-devel mailing list
>     [email-masked] <mailto:[email-masked]>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>

---

From: Robert Ancell <[email-masked]>
Date: Wed, 26 Jun 2013 17:53:20 +1200

This is the important point: if we put this into CI it wont just be your
time spent - it will be everyone else having to change their branches to
satisfy a GCC we're not requiring.

--Robert

On Wed, Jun 26, 2013 at 5:49 PM, Daniel van Vugt <
[email-masked]> wrote:

> machines, than I spend fixing the raring build failures (so I can build on
> my faster raring machine).
>
>>         <mailto:daniel.van.vugt@**canonical.com<[email-masked]>
>> >
>>         <mailto:daniel.van.vugt@__cano**nical.com <http://canonical.com>
>>
>>         <mailto:daniel.van.vugt@**canonical.com<[email-masked]>
>> >>>
>>
>>         wrote:
>>
>>
>>         <mailto:thomi.richards@**canonical.com<[email-masked]>
>> >
>>         <mailto:thomi.richards@__canon**ical.com <http://canonical.com>
>>
>>         <mailto:thomi.richards@**canonical.com<[email-masked]>
>> >>
>>
>>
>>     --
>>     Mir-devel mailing list
>>     [email-masked] <mailto:Mir-devel@lists.**ubuntu.com<[email-masked]>
>> >
>>
>>     https://lists.ubuntu.com/__**mailman/listinfo/mir-devel<https://lists.ubuntu.com/__mailman/listinfo/mir-devel>
>>     <https://lists.ubuntu.com/**mailman/listinfo/mir-devel<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>> >
>>
>>
>>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Jun 2013 13:54:11 +0800

Fair point. So don't CI it and I will wear the burden of owning raring 
support, as I already offered to.

On 26/06/13 13:53, Robert Ancell wrote:
> On Wed, Jun 26, 2013 at 5:49 PM, Daniel van Vugt
>     Put it this way: I will waste more time waiting for builds on my
>     saucy machines, than I spend fixing the raring build failures (so I
>     can build on my faster raring machine).
>
>         <mailto:[email-masked]>>
>                  <mailto:daniel.van.vugt@
>         <mailto:daniel.van.vugt@>__cano__nical.com <http://canonical.com>
>
>         <mailto:[email-masked]>>>>
>
>                  wrote:
>
>
>                  <mailto:thomi.richards@
>         <mailto:thomi.richards@>__canon__ical.com <http://canonical.com>
>
>         <mailto:[email-masked]>>>
>
>
>              --
>              Mir-devel mailing list
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         https://lists.ubuntu.com/____mailman/listinfo/mir-devel
>         <https://lists.ubuntu.com/__mailman/listinfo/mir-devel>
>              <https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>         <https://lists.ubuntu.com/mailman/listinfo/mir-devel>>
>
>
>

---

From: Gema Gomez <[email-masked]>
Date: Wed, 26 Jun 2013 08:10:15 +0100

Hey,

Why don't we just add some jobs to jenkins for Daniel to care for/look at?

Sounds like a compromise, Thomi can add them pretty easily then hand
them over to Daniel and job done from the mir team's perspective. They
don't even need to appear in any dashboard, they can be prefixed with
Daniel's name or some other prefix that excludes them from other
people's lists.

We have some jobs that are for a particular person or need, they are
testing something very particular and this doesn't need to be a burden
on others.

FWIW, Robert, I agree that automation is not always a blessing,
automation always comes at a cost, but if Daniel thinks it can help him
do something that otherwise is going to cause him (and possibly others)
grieve, then I think it may be worth at least trying.

Thomi, could we do that?

Just a thought in case it helps,
Gema

-- 
Gema Gomez-Solano        <[email-masked]>
Ubuntu QA Team           https://launchpad.net/~gema
Canonical Ltd.           http://www.canonical.com

---

From: Robert Ancell <[email-masked]>
Date: Thu, 27 Jun 2013 09:55:05 +1200

Sounds like a good solution to me.

On Wed, Jun 26, 2013 at 7:10 PM, Gema Gomez <[email-masked]

> >>                       Can we add raring CI support back in so these
> build
> >>                  problems get
> >>                       caught in time?
> >>
> >>
> >>         <mailto:thomi.richards@>__canon__ical.com <http://canonical.com
> >
> >>
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>