> First of all I think we'll have to live with UUID changes. Practically > speaking these are rarely a problem anyway (our UUID system is broken > in so many ways that the whole UUID dance is mostly for show)
How can we ensure that none of these UUID changes have add-on/web compatibility impact for desktop/mobile? > We might also want to relax the "builds must have passed green on > m-i/m-c". People need to be watching their landing after pushing > anyway and so I don't think it's that different from landing on m-c. I'm hearing that you'd like devs to be able to simul-land on m-c and m-a. If everybody's diligent about backing out when things go awry, I'm OK with that. Might get a little hairy when people are landing on top of each other on mozilla-aurora, since unraveling test failures from different pushes may be more difficult. -Alex On Oct 9, 2012, at 9:18 PM, Jonas Sicking <[email protected]> wrote: > On Mon, Oct 8, 2012 at 3:23 PM, Alex Keybl <[email protected]> wrote: >> [re-sending, looks like formatting was dropped] >> >> Hi Ehsan, >> >> Just got done discussing this with drivers. Gecko 18 will be the basis for >> B2G v1 as things stand today. Here's how things will play out. >> >> >> = Landing Process until 11/19, or until told otherwise (mozilla-aurora 18) = >> * Land on mozilla-aurora (a=blocking-basecamp) if your landing: >> ** first landed on m-i/m-c and the build/tests are green >> ** has zero risk to the current desktop/mobile feature set and users (unused >> API, ifdef'd out, etc.) >> ** is blocking-basecamp+ >> ** does not have string/UUID changes > > I'd like to request some changes to these rules in order to make B2G > development more sane. > > First of all I think we'll have to live with UUID changes. Practically > speaking these are rarely a problem anyway (our UUID system is broken > in so many ways that the whole UUID dance is mostly for show). It's > certainly always possible to avoid UUID changes, but doing so usually > require a lot of work and also introduces differences between > mozilla-central and the release branch. Such changes mean risk as well > as porting pain. > > We might also want to relax the "builds must have passed green on > m-i/m-c". People need to be watching their landing after pushing > anyway and so I don't think it's that different from landing on m-c. > > / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
