We need to set up all the regular mechanics for the new aurora branch. Assume for now that the repo will live at hg.m.o/releases/aurora. Update snippets should be diverted into a separate directory called 'aurora-bugXXX' for now.

update channel in the mozconfigs should be 'aurora'

The hg repo is at hg.m.o/mozilla-aurora

mozconfigs will be in a separate patch, and a graphserver bug/patch will be filed/uploaded soon. this is the main patch for the configs. mozilla-aurora, not being a release branch is in project_branches and mozilla-beta as a release line is in the main configs.

Comment on attachment 524981 [details] [diff] [review] adds mozilla-aurora, mozlilla-beta, and three additional twigs Looks good, except for this bit: + if key == 'platforms' and 'platforms' in BRANCHES[branch] and BRANCHES[branch].has_key('lock_platforms'): I think this should be "and BRANCHES[branch].get('lock_platforms')" so that you can explicitly set lock_platforms to False if you want.

Comment on attachment 524981 [details] [diff] [review] adds mozilla-aurora, mozlilla-beta, and three additional twigs landed on default: http://hg.mozilla.org/build/buildbot-configs/rev/8f28e701fbce

Comment on attachment 525107 [details] [diff] [review] aurora/beta mozconfigs Please use symlinks where all things are equal, eg: debug, qt configs -- except for Windows, where it's not supported. l10n-mozconfigs will need their --with-l10n-base option updated, not sure what that is for either yet, though. The aurora release mozconfigs aren't going to be used, so let's not even create them -- nightly needs to be on the "aurora" channel, though. Did we decide what to do about branding?

> Please use symlinks where all things are equal, eg: debug, qt configs -- except > for Windows, where it's not supported. When I discussed this with catlee and nthomas we agreed to either do all symlink or none, and not to do mix n match -- an attempt at consistency (with forgivness for windows) > l10n-mozconfigs will need their --with-l10n-base option updated, not sure what > that is for either yet, though. ok, i will check into this > The aurora release mozconfigs aren't going to be used, so let's not even create > them -- nightly needs to be on the "aurora" channel, though. got it. i'll make those corrections > > Did we decide what to do about branding? do we need to file a bug to get an --enable-aurora-branding? or is there another way being discussed?

ok so apparently according to gavin, we can leave out mention of branding and the 'default' will get picked up form within the repo files to get the appropriate branding.

(In reply to comment #9) > > Please use symlinks where all things are equal, eg: debug, qt configs -- except > > for Windows, where it's not supported. > > When I discussed this with catlee and nthomas we agreed to either do all > symlink or none, and not to do mix n match -- an attempt at consistency (with > forgivness for windows) Okay, WFM! > > Did we decide what to do about branding? > > do we need to file a bug to get an --enable-aurora-branding? or is there > another way being discussed? We actually discussed this on IRC, it looks like you'll want: --with-branding=browser/branding/aurora for aurora and probably browser/branding/beta for beta Gavin, can you confirm that?

The l10n-tree should be a mirror of l10n-central, and the l10n hg repos should be beneath http://hg.mozilla.org/l10n-aurora/, same for l10n-beta later down the line.

(In reply to comment #11) > We actually discussed this on IRC, it looks like you'll want: > --with-branding=browser/branding/aurora for aurora > and probably browser/branding/beta for beta Yeah, that flag is correct for aurora (pending the landing of the patch in bug 648368). I think beta will just want --enable-official-branding.

so i update the nightly channel for aurora - since there's no more release configs for it, the branding is not an issue actually and nor is l10n for beta, since it's a symlink of mozilla-central, it had the same branding settings (and l10n) as central. If that changes down the road we can replace the symlinks with hard copies

Comment on attachment 525201 [details] [diff] [review] aurora/beta mozconfigs This looks right for aurora. I'm not entirely clear on beta settings, but we have a bit more time to hash that out if it needs to change.

Comment on attachment 525201 [details] [diff] [review] aurora/beta mozconfigs landed on default & production http://hg.mozilla.org/build/buildbot-configs/rev/50bb9e31bef2

Comment on attachment 525099 [details] [diff] [review] data.sql update for aurora, beta, additional twig branches http://hg.mozilla.org/graphs/rev/cd860e182205

Comment on attachment 525366 [details] [diff] [review] Divert snippets http://hg.mozilla.org/build/buildbot-configs/rev/2cd087f712bc

Comment on attachment 525375 [details] [diff] [review] enable snippet creation for aurora Looks good to me.

Comment on attachment 525397 [details] [diff] [review] mobile needs its own download paths The enUS_binaryURL for aurora won't work, it needs to be a full URL. Looks fine otherwise.

Comment on attachment 525397 [details] [diff] [review] mobile needs its own download paths It's a bit confusing that enUS_binaryURL has a different format in project_branches.py, but I'm not sure how else to do this, since the download_base_url differs between product and staging.

Comment on attachment 525375 [details] [diff] [review] enable snippet creation for aurora http://hg.mozilla.org/build/buildbot-configs/rev/93f014b78357

Comment on attachment 525397 [details] [diff] [review] mobile needs its own download paths http://hg.mozilla.org/build/buildbot-configs/rev/9d83273be58a

(In reply to comment #25) > Comment on attachment 525397 [details] [diff] [review] > mobile needs its own download paths > > It's a bit confusing that enUS_binaryURL has a different format in > project_branches.py, but I'm not sure how else to do this, since the > download_base_url differs between product and staging. yes, we need to rely on the GLOBAL_VARS for now. I have a bug on getting some staging stuff ironed out for project_branches so this could likely be addressed in that bug 643467

Comment on attachment 525426 [details] [diff] [review] turn on mobile tests for aurora Thanks Lukas!

making this tracking-firefox5:? 649524: setup l10n repos for mozilla-aurora, mozilla-beta in particular this needs to be triaged and tracked daily until its complete, but since thats an IT bug it has no tracking-firefox5 flag.

Comment on attachment 525738 [details] [diff] [review] Re-enable updates on aurora i think your print len() statements might not want to stay in, r+ with those removed :)

Comment on attachment 525738 [details] [diff] [review] Re-enable updates on aurora Thanks, good catch! http://hg.mozilla.org/build/buildbot-configs/rev/d2d2d6c3ef57

what the summary says: moving mozilla-aurora into config.py because it's way more than a project_branch and no longer makes sense to keep it there, adding in the l10n_repo_paths as per bug 649524, and temporarily disabling nightlies on the mozilla-beta branch to save resources until they are needed in ~5 weeks.

Comment on attachment 525901 [details] [diff] [review] move aurora to configs from project_branches, fix l10n repos, temp disable mozilla-beta nightlies http://hg.mozilla.org/build/buildbot-configs/rev/6f910a2ffc4f on default

Comment on attachment 526141 [details] [diff] [review] add aurora to the gcc-4.3.3 loop in mozilla/config.py *stamp*

kicked 649782 out of the dep list and added it to blocking. this branch is setup.

All setup work is done.