Short term, my preference is also to disable the test until the Gecko
fix lands in m-c.
Long term, we would only have TBPL running our test suites and we would
have a one-to-one relationship between Gaia and Gecko branches. So,
b2g-inbound and gaia-inbound, mozilla-central and gaia-central (aka
master now). For Gecko/Gaia "atomic" patches, we could have a signal on
the first of the two commits that it shouldn't run tests.
Having Gaia part of the Gecko repo would clearly be a big burden for new
contributors.
On 07/11/13 18:23, Fabrice Desré wrote:
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
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
