ReleaseEngineering:ProjectBranchPlanning: Difference between revisions

Deprecated
No edit summary
(Deprecated)
 
(14 intermediate revisions by 7 users not shown)
Line 1: Line 1:
If your need for an automated branch is of a known length of time, please book a [https://wiki.mozilla.org/DisposableProjectBranches Disposable Project Branch], otherwise if you are looking for a longer term solution and want a new project branch created for your work, please file a bug with this [http://bit.ly/NewProjectBranchTemplate bug template]
Deprecated in favor of [https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectRepositories Disposable Project Branch]
 
Copy the questions below, and insert your answers in the bug's comment section so we have the info we need:
 
* Project name:
** Your project name will also be used for the repo name (eg: hg.mozilla.org/projects/jaegermonkey) - please state if you have an existing repo you're looking to use instead of a newly created repo.
** Note: project names should avoid using confusing/overloaded terms, like "build", "firefox", "release"...
** Note: Repos for finite-duration project branches will go into [http://hg.mozilla.org/projects http://hg.mozilla.org/projects]. Repos for never-ending team/integration branches will go into [http://hg.mozilla.org/integration http://hg.mozilla.org/integration"].
 
* For builds:
** All platforms or subset of platforms currently building mozilla-central?
** Will you use the mozilla-central mozconfigs or will you need custom ones?
** Nightly builds?
 
* Need unittests?
** All platforms or subset of platforms currently testing mozilla-central?
 
* Mobile Builds?
** All platforms or subset of platforms currently building mobile-browser?
 
* Need Talos?
** All talos suites or a subset of suites run on mozilla-central?
 
* Name of the contact person for this branch who will:
** Be doing periodic refreshes from parent
** Be contact person for misc setup questions
** Decide when to land back project branch onto parent
** Decide when to terminate the project branch
 
* Timeline:
** When should this branch go live?
** Approx expected life span of project branch?
 
= Release Engineering Project Branch Creation Checklist =
 
* File a ServerOps bug to create repo in hg.m.o if repo does not already exist. Repos should be created under "/projects", "/services" or "/releases" whenever possible.
* [http://tinderbox.mozilla.org/admintree.cgi Create tinderbox page] for the branch to report to
* Create a patch on [http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/file/tip/js/Config.js tbpl] to add the branch to tbpl (currently the reviewer of choice is Ehsan)
* Once that is reviewed and landed you can [https://intranet.mozilla.org/RelEngWiki/index.php/How_To/Update_Tinderbox_Pushlog_%28tbpl%29 Update TBPL]
* Create patches in buildbot-configs/mozilla/project_branches adding the project and if needed any custom mozconfig path or custom repo path
** By default, the project branches use the generic mozconfigs (in buildbot-configs/mozilla2/$platform), if you need custom mozconfigs you should create them across the board as we would prefer at this time to not have a mix of files and symlinks. You can override the 'mozconfig_dir' in the project_branches.py file
** Example customization is turning on nightly updates, if this comes up you can copy the process from the UX branch see [https://bugzilla.mozilla.org/attachment.cgi?id=531789 example patch] for what is required wrt AUS, once you've enabled nightlies you need to land in cvs, tag and then file a ServerOps bug ([https://bugzilla.mozilla.org/show_bug.cgi?id=657008 example])
** If you do enable custom nightly channels for a project branch there is a Mac specific issue caused by publishing snippets to a Darwin_x86_64-gcc3 directory, and the clients querying using different build targets so you should use the templates nthomas set up:
# ffxbld@aus2-staging
$ rsync -av ~/template/ /opt/aus2/incoming/2/Firefox/<new_branch_name>/
* Do an update to branch and machines tables in graphs/sql/data.sql (branch 1.0 of this repo)
* File a ServerOps bug (example {{bug|633663}}) to add graphserver entries until this is automated (see {{bug|627499}})
* Add to self-serve ([https://wiki.mozilla.org/ReleaseEngineering/BuildAPI#Adding_branches instructions])
 
Once the above items are done and a few pushes have gone through without issue, close the bug - you're done!
 
== Additional Steps For Adding Release Branches ==
 
* File IT bugs:
** to add Nagios monitoring on checks for file age in firefox/nightly/latest-$branch if required
** to add mxr indexing (release branches only - see [https://bugzilla.mozilla.org/show_bug.cgi?id=510495 bug 510495] for example)
* File a Webtools/Socorro bug to add the new branch to vcsMappings:
** This allows devs to get source links for branch crash reports.
** Ask for this:
<pre>'hg.mozilla.org/REPO' => 'http://hg.mozilla.org/REPLACE_WITH_REPO/annotate/%(revision)s/%(file)s#l%(line)s'</pre>
 
* Make sure to add mozconfigs for each platform!
Confirmed users
4,971

edits