to do it, as I can tell when a patch I've
> written gets pushed, then backed out due to results on treeherder.
>
> On 7/11/16, Jonathan Griffin wrote:
> > Yes, a clear Yes/No answer for Try pushes is something we'd like to be
> able
> > to report.
> >
as I can tell when a patch I've
> written gets pushed, then backed out due to results on treeherder.
>
> On 7/11/16, Jonathan Griffin wrote:
> > Yes, a clear Yes/No answer for Try pushes is something we'd like to be
> able
> > to report.
> >
> >
Yes, a clear Yes/No answer for Try pushes is something we'd like to be able
to report.
Currently, interpreting Try results can be hard for a few reasons:
1 - intermittent test failures make it hard to separate failures your push
has caused vs pre-existing failures
2 - people sometimes push to try
Hi all,
Kyle Lahnakoski has developed a dashboard, based on ActiveData [1], which
displays durations of builds produced by automation:
http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Builds-Overview.html
Although much of the focus of the "build faster" work this quarter is for
local bui
I've also scheduled Laurelhurst Friday @ 2pm for a similar discussion,
so we should figure out if we need both. :)
There is a large releng/a-team coordination meeting Tuesday from 3-5pm,
so there wouldn't be a lot of a-teamers available at the Tuesday time.
It may be we can use the Friday me
I think we're still trying to figure out which parts it makes sense for
us to own. If you have some ideas about how to fundamentally improve
things starting with the build system, that sounds pretty interesting.
Let's collaborate to make sure we're not duplicating effort. +1 for a
meeting in
6 matches
Mail list logo
