Re: Gecko 17 as the base for B2G v1
On 8/1/12 2:47 PM, Alex Keybl wrote: ... and on 11/19 work will move to the mozilla-esr17 branch. I don't really understand this, perhaps I am missing something? ESR and a v1.0 product seem inherently at odds. EG, I would assume that B2G will be making substantial and even high-risk changes right up to the day of release (and afterwards, should a 1.1 thing be needed). That's obviously different than ESR's primary goal, and even aurora/beta. I would have guessed B2G would want to create something like a mozilla17-b2g branch -- a stable (wrt non-B2G changes) Gecko 17 base, pulling in changes from aurora-17 / beta-17 as those trains run. But also allowing any changes B2G wants without worrying about impact to other products. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko 17 as the base for B2G v1
On 8/2/12 1:44 AM, Andreas Gal wrote: Reporting of the results and integration is very lacking, and until those pieces fall into place (e.g. try integration), the developer experience is going to suck a lot if we enforce the rule below (backout). That's the concern, yes. Basically, if we're going to have the rules proposed at the level of testing we have now then the path of least resistance for me is probably to land nothing else for the rest of the 17 cycle because it almost certainly save me a bunch of time to do things that way... If we get to a point where we have decent try test coverage, it's a different story. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko 17 as the base for B2G v1
We have test coverage using emulators, and actual hardware (panda boards) is being set up. Reporting of the results and integration is very lacking, and until those pieces fall into place (e.g. try integration), the developer experience is going to suck a lot if we enforce the rule below (backout). We might want to try a coordinate instead of the automatic back out approach. If some change breaks B2G, we will try to negotiate with the patch author whether we can back it out and land it later or back it out and we help fix the B2G regression and then re-land etc. If you break B2G, the feedback is not immediate, and there is almost no fair and reasonable way for general m-c committers to predict and test for B2G regressions (the A team is working really hard on fixing this). Andreas On Aug 1, 2012, at 9:30 PM, Boris Zbarsky wrote: On 8/1/12 5:47 PM, Alex Keybl wrote: any desktop/mobile change that negatively impacts B2G builds in a significant way will be backed out (and vice versa). Do we have any sort of B2G test coverage? Ideally on try? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
