A new FTBFS every day

[Robert Ancell]

Sounds like a good solution to me.


On Wed, Jun 26, 2013 at 7:10 PM, Gema Gomez <gema.gomez-solano at canonical.com
> wrote:

> 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
>
> On 26/06/13 06:54, Daniel van Vugt wrote:
> > 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:
> >> 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
> >> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> >> wrote:
> >>
> >>     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
> >>         <daniel.van.vugt at canonical.com
> >>         <mailto:daniel.van.vugt at canonical.com>
> >>         <mailto:daniel.van.vugt at __canonical.com
> >>         <mailto:daniel.van.vugt at canonical.com>>>
> >>
> >>         wrote:
> >>
> >>              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
> >>                  <daniel.van.vugt at canonical.com
> >>         <mailto:daniel.van.vugt at canonical.com>
> >>                  <mailto:daniel.van.vugt at __canonical.com
> >>         <mailto:daniel.van.vugt at canonical.com>>
> >>                  <mailto:daniel.van.vugt@
> >>         <mailto:daniel.van.vugt@>__cano__nical.com <
> http://canonical.com>
> >>
> >>                  <mailto:daniel.van.vugt at __canonical.com
> >>         <mailto:daniel.van.vugt at canonical.com>>>>
> >>
> >>                  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
> >>         thomi.richards at canonical.com
> >> <mailto:thomi.richards at canonical.com>
> >>                  <mailto:thomi.richards at __canonical.com
> >>         <mailto:thomi.richards at canonical.com>>
> >>                  <mailto:thomi.richards@
> >>         <mailto:thomi.richards@>__canon__ical.com <http://canonical.com
> >
> >>
> >>                  <mailto:thomi.richards at __canonical.com
> >>         <mailto:thomi.richards at canonical.com>>>
> >>
> >>
> >>              --
> >>              Mir-devel mailing list
> >>         Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
> >>         <mailto:Mir-devel at lists.__ubuntu.com
> >>         <mailto:Mir-devel at lists.ubuntu.com>>
> >>
> >>              Modify settings or unsubscribe at:
> >>         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>>
> >>
> >>
> >>
> >
>
>
> --
> Gema Gomez-Solano        <gema.gomez-solano at canonical.com>
> Ubuntu QA Team           https://launchpad.net/~gema
> Canonical Ltd.           http://www.canonical.com
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20130627/d9511ff6/attachment.html>