Another question/suggestion about this process: Basically any b2g bug will need either approval-aurora or blocking-basecamp. Otherwise it's effectively b2g v2 work, and nobody is working on v2 at the moment.
If I have a bug that's not a basecamp blocker that I'd like to get into b2g, this means that I have to wait for an Aurora triage session before I can land it and have it available on Aurora. I expect we will soon modify our main b2g repository to point at mozilla-aurora instead of mozilla-central (since we won't be shipping mozilla-central v19 in b2g v1), which means that no other b2g devs will get my change until it lands on Aurora. Will be running mozilla-aurora triage once a day? Otherwise, how long should I expect to wait before I can land non-blockers on mozilla-aurora? In order to meet our deadline, it's critical that we be able to share patches with others quickly. If I have to wait days to get my non-basecamp-blocking bugs landed on Aurora, that will slow us down to an unacceptable level. We do b2g triage once a day. If we can't do Aurora triage once a day, perhaps we can add a b2g-v1-approval flag which is equivalent to a fast-tracked aurora-approval flag. (Even better, b2g-v1-approval could go on the bug, instead of on the patch, which would further reduce lag before landing.) -Justin On Mon, Oct 8, 2012 at 6: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 > > * If your bug does not meet the above requirements (or if in doubt), mark the > bug with approval-mozilla-aurora? as always and fill out the risk assessment. > These are triaged as quickly as possible (every 1-2 weekdays). > > * Once landed on mozilla-aurora (standard stuff): > ** mark status-firefox18:fixed > ** paste the m-a hg link in the associated bug > ** watch TBPL and back out the change if the build doesn't go green > ** back out B2G changes on mozilla-aurora if backed out on mozilla-central > for whatever reason > > * We will revoke the quick a=blocking-basecamp landing if it poses major risk > to Aurora desktop/mobile users or if devs do not follow the guidelines above. > At that point, all landings will first go through approval-mozilla-aurora? > triage. > > > = Landing Process after 11/19 (mozilla-beta 18) = > * All landings will be required to go through approval-mozilla-beta? triage > > > Jonathan will need to move Nightly/Stable builds over to mozilla-aurora from > mozilla-central for tonight's build, given the FF18 base. Please let me know > if anybody has questions about the above decisions or process. > > -Alex > > On Oct 2, 2012, at 10:47 AM, Ehsan Akhgari <[email protected]> wrote: > >> Hi all, >> >> Has there been a call on which version of Gecko b2g v1 will be based on? We >> need to know whether we can backout bug 722845 on 18 after the uplift to >> Aurora until we fix bug 787743 on trunk, and in order to make that call we >> need to know whether b2g will be shipping off of Gecko 18 or trunk (which >> will be Gecko 19 in about a week), since b2g depends on the work in bug >> 722845. >> >> Thanks! >> Ehsan >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
