> I believe this was answered in my original email. You're right; I missed this bullet. Sorry!
> mark the bug with approval-mozilla-aurora? Do you mean, mark the /patch/ with approval-mozilla-aurora? This is a big difference from basecamp-blocking in that (traditionally, anyway) I must have a reviewed patch before I can ask for approval. That means that I basically cannot ask for pre-approval, which means that the Aurora triage is always on my critical path (whereas basecamp triage is not, because we basecamp-blocking+ bugs, not patches). But if you guys are doing Aurora triage at least every 48 hours, that may be fast enough; I guess we'll have to see. On Tue, Oct 9, 2012 at 9:16 AM, Alex Keybl <[email protected]> wrote: > I believe this was answered in my original email. > >> * 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). > > We will triage as quickly as shipping products allow. Feel free to ping > anybody on the release management team to fast track a specific approval. > > -Alex > > On Oct 8, 2012, at 8:49 PM, Justin Lebar <[email protected]> wrote: > >> 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
