> Do you mean, mark the /patch/ with approval-mozilla-aurora? Correct, we should be marking the patch with approval-mozilla-aurora?.
> 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). Yep - we're on your critical path if the patch poses risk to desktop/mobile or doesn't have blocking-basecamp+. Otherwise, a=blocking-basecamp. -Alex On Oct 9, 2012, at 7:40 AM, Justin Lebar <[email protected]> wrote: >> 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
