Hi Ed,
On 11/07/2013 04:00 AM, Ed Morley wrote:
> Hi all
>
> Last night bug 891882 landed, which broke the gaia ui tests for B2G
> desktop on TBPL on b2g-inbound. This was backed out as a result, but
> then relanded by the patch author, since they said the failures were
> expected until they had landed the gaia counterpart. The gaia tests
> counterpart wasn't being landed at the time, since it was waiting on a
> green travis run, which required the gecko changes to have merged to
> mozilla-central (travis uses the m-c builds).
>
> This was suboptimal for a few reasons:
>
> (To be clear, I don't blame the assignee of that bug - it isn't the
> first time this scenario has occurred - we just need to agree on a
> workflow and document/announce it, so as to avoid these problems in the
> future)
You can blame me, as I clearly did the wrong thing. I overreacted after
the first backout because the sheriff did not contact me beforehand to
try to find the solution (we could have landed the skip-test fix at this
time) and I apologize for that.
> [snip] the drama
>
> Alternative workflows to the above are:
>
> a) Land the gaia change even if the travis run isn't green, so that
> TBPL is back to being green asap (and [2c] above can be ruled out).
I don't think gaia people are ok with breaking travis instead of
breaking tbpl...
> b) [My preference]: First make a gaia change to disable the tests (or
> make them feature-detect so they are backwards-compatible), then once
> that's on mozilla-central, land the gecko change on b2g-inbound (since
> the travis run will be green), then once that is on mozilla-central land
> another gaia change to remove the support for the previous API/...
>
> Unless anyone has any other ideas?
This is what we do usually. I just failed yesterday.
> Also - what do we think about getting Travis to use the b2g-inbound
> builds rather than mozilla-central? (In order to reduce the cycle time
> when needing to make gecko changes)
The issue is that gaia-master is not an integration branch, it's the
equivalent of m-c so that doesn't look like a good idea. I proposed to
have an inbound branch on gaia that would do that but this was - at
least temporarily - rejected in favor of the "shepherd" tool. But I
don't think that shepherd will help us at all in these cases since
shepherd is gaia centric.
The other alternative to make it painless to land gecko+gaia atomic
changes is of course to move gaia to the same repo as gecko, and make
the github repo a readonly mirror of gaia-hg. I'm sure I will be very
popular with this proposal in gaia circles ;)
Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
