ReleaseEngineering:ProjectBranchPlanning: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(Deprecated)
 
(27 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 projects/ one.
** Note: project names should avoid using confusing/overloaded terms, like "build", "firefox", "release"...
 
* 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 Checklist =
 
* [http://tinderbox.mozilla.org/admintree.cgi Create tinderbox page] for the branch to report to
* File bug for addition to tbpl (WEBTOOLS->TBPL)
* Create patches in buildbot-configs adding the project name and if needed any custom mozconfig path or custom repo path (RELENG)
* Bug for Graphserver entries until this is automated (see {{bug|627499}})(SERVER OPS)
* Add to self-serve (RELENG)
 
== Old info which needs reviewing for relevance ==
 
* File IT bugs:
** to add nagios monitoring
** to add mxr indexing (release branches only - see [https://bugzilla.mozilla.org/show_bug.cgi?id=510495 bug 510495] for example)
** to get rows added to graph server database:
*** branches table for talos results (if applicable)
*** machines table for the branch/platform's build/leak test results (if applicable)
 
* 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>
 
** mozilla (schedulerdb land)
** <strike>mozilla2 (production-master)</strike>
** <strike> mozilla2-staging (staging-master)</strike>
** mobile configs if applicable
** talos-r3 (talos-master, if applicable)
** talos-staging-pool (talos-staging-master, if applicable)
** Make sure to add mozconfigs for each platform!
 
* Test staging patches - watch for mozconfigs, talos sendchanges working, file uploads to staging-stage
 
* Push and enable production and staging patches
* Schedule downtime and reconfig Talos
 
* Set up Nagios monitoring on checks for file age in firefox/nightly/latest-$branch if required
 
[https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning:UnittestOptions Brief Note about Unittests]

Latest revision as of 18:40, 14 December 2021

Deprecated in favor of Disposable Project Branch