MozillaWiki

Bugzilla:Release Process: Difference between revisions

Bugzilla Discussion

Bugzilla:Release Process (view source)

Revision as of 03:29, 20 February 2018

1,576 bytes removed ,  20 February 2018
no edit summary
(Added notes about security release as well as a detailed description of the release process.)
No edit summary
 
(22 intermediate revisions by 5 users not shown)
Line 3: Line 3:
== Security Releases ==
== Security Releases ==


All security bugs to be triaged one business day by a Assistant Project Leader or Project Leader. Along with the Mozilla Security Team, it should be determined if the issue is valid, and the severity (the sec-low, sec-moderate and sec-high keywords is normally used for this).
All security bugs should be triaged as soon as possible by the Bugzilla team. Along with the Mozilla Security Team, it should be determined if the issue is valid, and the severity (the sec-low, sec-moderate and sec-high keywords is normally used for this).


A high security bug would include (but is not limited to) data leakage (including CSRF/XSS attacks) or when the exploit is already publicly available (as was the case with bug 1036213). This would also include
A high security bug would include (but is not limited to) data leakage (including CSRF/XSS attacks) or when the exploit is already publicly available (as was the case with bug 1036213). This would also include
Line 14: Line 14:
== Version Numbers ==
== Version Numbers ==


Major version increases (e.g. 5.0) reflect large, visible, and/or breaking changes.  These would include features being removed, interfaces being changed, dependencies being updated, significant UI changes, major new features, etc.
Major version increases (e.g. 5.0) reflect large, visible, and/or breaking changes.  These would include major features being removed or added, interfaces being changed, significant UI changes, etc.


Minor version increases (e.g. 5.2) reflect noncritical bugfixes, small new features, and other nonbreaking changes.  These would include additions and/or backward-compatible changes to interfaces, support for new technologies or platforms, and general improvements and fixes.  Note that official releases will always have an even-numbered minor version (e.g. 5.0, 5.2, 5.4); odd numbers are reserved for development releases.  This applies only to the minor version number.
Minor version increases (e.g. 5.2) reflect smaller new features, and other nonbreaking changes.  These would include additions and/or backward-compatible changes to interfaces, support for new technologies or platforms, and general improvements and fixes.  Note that official releases will always have an even-numbered minor version (e.g. 5.0, 5.2, 5.4); odd numbers are reserved for development releases.  This applies only to the minor version number.


Patch version increases (e.g. 5.2.1) usually reflect critical fixes, such as to security or other severe bugs.  While we generally wait until there is a critical fix to release a patch version, these versions may also contain other minor fixes committed in the meantime.  We may also occasionally release a patch version without critical fixes if there is a sufficiently large backlog of minor fixes, or for development snapshots (of an odd-numbered minor version).
Patch version increases (e.g. 5.2.1) usually reflect critical fixes, such as to security or other severe bugs.  While we generally wait until there is a critical fix to release a patch version, these versions may also contain other minor fixes committed in the meantime.  We may also occasionally release a patch version without critical fixes if there is a sufficiently large backlog of minor fixes, or for development snapshots (of an odd-numbered minor version).
Line 22: Line 22:
== When to Release ==
== When to Release ==


In [[Bugzilla:Meetings:2014-05-28|May 2014]] we decided to try to release approximately every 6 months with whatever is ready at the time. This gets new features out the door more quickly.  Branching should be done when master is relatively stable, but sometimes branching with known bugs is acceptable if it allows other large, potentially unstable features to land (for the next release).  If there are bugs related to new features in the release branch, the feature should be backed out of the release branch (if it's very recent), or fixes should be committed to both the release branch and master.  Bugs blocking release should be denoted with a blocking<version> flag, e.g. blocking5.0.
We release approximately once per year with whatever is ready at the time. Branching should be done when master is relatively stable, but sometimes branching with known bugs is acceptable if it allows other large, potentially unstable features to land (for the next release).  If there are bugs related to new features in the release branch, the feature should be backed out of the release branch (if it's very recent), or fixes should be committed to both the release branch and master.  Bugs blocking release should be denoted with a blocking<version> flag, e.g. blocking5.0.


The version number will be determined at time of branching depending on the changes included, as per the section above.  Note that this means we may have back-to-back major releases.
The version number will be determined at time of branching depending on the changes included, as per the section above.
 
== What to Release ==
 
As stated above, generally master will be branched approximately six months after the previous release, but there may be additional bugs to be fixed.  In August 2014, at the [[Bugzilla:Meetings:2014-08-27|public meeting]] and follow-up [https://groups.google.com/forum/#!topic/mozilla.dev.apps.bugzilla/2igVLzJ26h4 newsgroup discussion] we decided that the Target Milestone should be used to denote things that should be fixed before release, i.e., blockers, or bugs being actively worked on.  Release candidates should only be created after there are zero open bugs with the Target Milestone set to that release.  Furthermore, only the bug's assignee or a Bugzilla reviewer/approver should set or unset the Target Milestone.
 
The existing policy of having approvers set or update the Target Milestone, if necessary, on bugs that are committed before an upcoming release continues unchanged.


== Release Process Details ==
== Release Process Details ==
Line 42: Line 36:
* Release Notes: Point releases and rc1 versions need release notes. Each version being released needs a separate Release Notes bug filed. These bugs should block the first bug. For final releases of major versions, you need a "clean up release notes" bug. (Sample: bug 1042088)
* Release Notes: Point releases and rc1 versions need release notes. Each version being released needs a separate Release Notes bug filed. These bugs should block the first bug. For final releases of major versions, you need a "clean up release notes" bug. (Sample: bug 1042088)
* New Features Page (Release Candidates and Final Releases Only): Make this bug depend on the appropriate Release Notes bug. (Sample: bug 286278)
* New Features Page (Release Candidates and Final Releases Only): Make this bug depend on the appropriate Release Notes bug. (Sample: bug 286278)
=== Motivate People ===
Basically, just make it really easy to find and access all the bugs that need to be fixed for the release. I usually do this a few days after I file the above bugs.
This means:
* Do a search for blockers for the release, and make the query link into a tinyurl. When creating a tinyurl, make sure that no "order by" information is part of the URL so that you don't break people's LASTORDER cookies.
* Put that tinyurl at the very end of the topic line of the #mozwebtools IRC channel on irc.mozilla.org, with a brief explanation like "4.0.11 Blockers: tinyurl".
* Send out an email to developers@bugzilla.org explaining that we're releasing, and include the tinyurl. Having just one link in the email gets people to focus a bit more.
* If you are desperate: Send out an email to support-bugzilla with a tinyurl pointing to all bugs targeted at your release, sorted by Importance. Explain that you'd like some help, and link them also to the Contributor's Guide
* Do not include any sensitive security information in the email announcements yet.


=== Pre-Release ===
=== Pre-Release ===
Line 66: Line 48:


   Class:      Cross-site scripting
   Class:      Cross-site scripting
   Versions:    2.15 through 2.18rc3 and 2.19.1 (from cvs)
   Versions:    2.15 through 2.18rc3 and 2.19.1
   Description: It is possible to blah blah blah
   Description: It is possible to blah blah blah
                 And here are some details on how it can be made less bad...
                 And here are some details on how it can be made less bad...
Line 76: Line 58:
==== Determining Affected Versions ====
==== Determining Affected Versions ====


It also can be a bit tricky to determine the earliest version affected by a security bug. What I do is use Loggerhead's "Files" interface to find the place where the patched code was first introduced. (That is, the code the Security bug is modifying.) Then, by looking at the Changes log in Loggerhead, you can match that up with the dates on the Release Information page.
It also can be a bit tricky to determine the earliest version affected by a security bug. git blame can help you find the place where the patched code was first introduced (that is, the code the Security bug is modifying) and which bug introduced it.


==== Getting it Reviewed ====
==== Getting it Reviewed ====


Security Advisories get sent to security@bugzilla.org for review. Allow at least two or three days for the members of the list to respond.
Security Advisories must be reviewed by a member of the Bugzilla team. If you don't get a response after two or three days, check with people on IRC and get them to look at it.
 
If you don't get a response after three or four days, that probably means the advisory is fine. But still check with people on IRC and get them to look at it.


=== Release Notes ===
=== Release Notes ===


The actual process of writing Release Notes is described in the Release Noting Guide. The important thing to remember about Release Notes is that they should be sent to reviewers@bugzilla.org for comment. Give the list about two days to respond.
The actual process of writing Release Notes is described in the [https://www.bugzilla.org/docs/releasenote.html Release Note Guide]. They should also be attached normally to the bug, and you should ask some reviewer to look over them.
 
They should also be attached normally to the bug, and you should ask some Documentation reviewer to look over them.


=== Web Site Updates ===
=== Web Site Updates ===


Check Out From CVS (needs to be put into Git)
In order to update the website, the first thing you have to do is check out its code from Git. Make sure you have checkin access on Github:
 
In order to update the website, the first thing you have to do is check out its code from CVS. The best place to do this is on landfill, because it already has the environment set up to be able to fully build the website. Make sure you have checkin access on cvs.mozilla.org.
 
The CVS info is:


  CVSROOT=\:ext\:user%domain.com@cvs.mozilla.org\:/www
  git@github.com:bugzilla/bugzilla.github.io
  cvs -z3 checkout bugzilla-org


Or, if you don't have checkin access, but you want to work on the web site updates anyhow, the CVSROOT for anonymous access is:
Or, if you don't have checkin access, but you want to work on the web site updates anyhow:


  CVSROOT=\:pserver:anonymous@cvs-mirror.mozilla.org\:/www
  https://github.com/bugzilla/bugzilla.github.io


==== Automatic Website Updater ====
==== Automatic Website Updater ====
Line 109: Line 82:
There is now a script that does most of the web site updates for a release, called bin/do-release.pl in the website checkout. You use it like this:
There is now a script that does most of the web site updates for a release, called bin/do-release.pl in the website checkout. You use it like this:


bin/do-release.pl --security=3.2.6 3.7.1 3.6.1 3.4.7 3.2.7
bin/do-release.pl --security=4.2.15 4.4.10 5.0.1


That updates your local checkout as though you were going to do a release of 3.7.1, 3.6.1, 3.4.7, and 3.2.7, with a security advisory where the lowest unfixed version being fixed was 3.2.6.
That updates your local checkout as though you were going to do a release of 4.2.15, 4.4.10 and 5.0.1, with a security advisory where the lowest unfixed version being fixed was 4.2.14.


This script will update the files in your checkout appropriately for the release, and will also print a lot of messages like "** Remember to update some/file.html". Those "remember" messages are files that are not updated by the script, and will have to be updated by you. The updates that need to be done to those files are described below in the "Manual Website Updating" section below.
This script will update the files in your checkout appropriately for the release, and will also print a lot of messages like "** Remember to update some/file.html". Those "remember" messages are files that are not updated by the script, and will have to be updated by you. The updates that need to be done to those files are described below in the "Manual Website Updating" section below.
Line 123: Line 96:
Before we had the automatic updater script, we used to do all the website updates by hand. This section preserves the full instructions for how to update the website for a release, in case you need to understand exactly what the automatic script is doing, or in case you need to understand how to update one of the files that the script doesn't update.
Before we had the automatic updater script, we used to do all the website updates by hand. This section preserves the full instructions for how to update the website for a release, in case you need to understand exactly what the automatic script is doing, or in case you need to understand how to update one of the files that the script doesn't update.


* Create a directory for the Security Advisory. The directory is always numbered by the lowest unfixed version that is being fixed. For example, if you release versions 2.16.9, 2.18.1, and 2.19.3, and they all have a single Security Advisory, the security advisory goes into the 2.16.8/ directory.
* Create a directory for the Security Advisory. The directory is always numbered by the lowest unfixed version that is being fixed. For example, if you release versions 4.2.15, 4.4.10 and 5.0.1, and they all have a single Security Advisory, the security advisory goes into the 4.2.14/ directory.
* For each new release, create a "Release Info" page:
* For each new release, create a "Release Info" page:
** Create a directory in the releases/ directory for the new release.
** Create a directory in the releases/ directory for the new release.
Line 156: Line 129:


* Update Bugzilla/Constants.pm's BUGZILLA_VERSION variable.
* Update Bugzilla/Constants.pm's BUGZILLA_VERSION variable.
* Update docs/en/xml/Bugzilla-Guide.xml. bz-ver, bz-date, bz-nextver, and current-year need to be updated. You may also have to update landfillbase if you just branched.
* For Bugzilla 4.4, you must also update docs/bugzilla.ent.tmpl. bz-ver, bz-date, and current-year need to be updated. You may also have to update landfillbase if you just branched.
* For 4.3 and newer, instead of docs/en/xml/Bugzilla-Guide.xml you need to update docss/bugzilla.ent.tmpl.


=== Tag the Releases in CVS (4.0 only), Bzr, and Git ===
=== Tag the Releases in Bzr, and Git ===


To tag a release using CVS for the 4.0 branch:
'''TODO''': This should all be a script at some point


  cvs -q up -dP
To tag a release in Bzr for the 4.4 branch:
  cvs status -v query.cgi | less
  cvs -Q tag -FR BUGZILLA-4_0_6
  cvs -Q tag -R -d BUGZILLA-4_0-STABLE
  cvs -Q tag -FR BUGZILLA-4_0-STABLE
  cvs -Q tag -FR Bugzilla_Stable


To see the current tags in CVS:
'''Note:''' bzr.bugzilla.org now resides on the community infrastructure and requires shell access to make the tags manually. Find dkl or justdave to get access. The BZR branches are located in /var/www/html/bzr.bugzilla.org/bugzilla.


http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/webtools/bugzilla/Bugzilla/Constants.pm
   bzr tag bugzilla-4.4.11
 
To tag a release in Bzr for the 4.0 branch:
 
   bzr tag bugzilla-4.0.14
   bar tag --force bugzilla-stable
   bar tag --force bugzilla-stable


To tag a release in Git for the 4.0 branch:
To tag a release in Git for the 4.4 branch:
    
    
  git checkout 4.0
  git tag bugzilla-4.0.14 <commitid>
  git push origin bugzilla-4.0.14
  git push --delete origin bugzilla-4.0.14 (to remove a tag if needed)
Stable release tag in git:
   git checkout 4.4
   git checkout 4.4
   git push --delete origin bugzilla-stable
   git tag bugzilla-4.4.11 <commitid>
   git tag -f bugzilla-stable <commitid>
   git tag release-4.4.11 <commitid>
   git push origin bugzilla-stable
   git push origin bugzilla-4.4.11
  git push origin release-4.4.11
  git push --delete origin bugzilla-4.4.11 (to remove a tag if needed)


=== Generate Files to Release ===
'''Note:''' Since 5.0, we only use the release-x.x.x tag form for 5.0 and future releases.


==== Create the Tarballs ====
Creating stable release branch in git initially:


First, wait about 5 minutes after you do the tags. This is to allow the version bumps to propogate from Git to Bzr and also to CVS. The latter is because tarballs for 4.0 are pulled from cvs-mirror.mozilla.org, and you need to wait for that server to be updated with the tags.
  git checkout 4.4
  git branch release-4.4-stable <commitid>
  git push origin release-4.4-stable


There's a script for building Bugzilla tarballs, in the misc/build bzr repository.
Updating stable release branch after bumping version number step:


Just build a tarball for each release, using the version-specific CVS or bzr tags that you made above. (Don't use the -BRANCH or _Stable tags.)
  git checkout release-4.4-stable
  git merge release-4.4.11
  git push


For building the 4.0.x tarballs:
=== Generate Files to Release ===


  bin/buildtarball.sh BUGZILLA-4_0_14 bugzilla-4.0.14
==== Create the Tarballs ====


For building tarballs for 4.2.x and newer:
For building tarballs for 4.2.x and newer:


   bin/build.pl 4.2 4.2.10
   ./build.pl 4.2.15
   bin/build.pl 4.4 4.4.5
   ./build.pl 4.4.10
   bin/build.pl trunk 4.5.5
   ./build.pl 5.0.1


==== Make the Diff Files ====
==== Make the Diff Files ====
Line 223: Line 185:
==== Post the Files ====
==== Post the Files ====


Using sftp or scp, upload the tarballs and .diff.gz files to stage.mozilla.org, to the /pub/mozilla.org/webtools directory.
Mozilla recently migrated specific files on ftp.mozilla.org to be served from Amazon S3 buckets. In order to upload the tar files and diffs to S3, you will need to have access keys assigned to your account. dkl and justdave currently have access keys so either of them can upload the files.
 
You will need to download and install the aws-cli client from github.
 
http://docs.aws.amazon.com/cli/latest/userguide/installing.html#install-bundle-other-os
 
Create an .aws directory in your user's home directly.
 
Generate an .aws/credentials file containing your access keys assigned to you.
 
  [default]
  aws_access_key_id=<ACCESS_KEY>
  aws_secret_access_key=<SECRET_ACCESS_KEY>
 
Generate an .aws/config file that specifies the region desired.
 
  [default]
  region=us-east-1
  output=json
 
To copy a file to S3 available for download. Need to do for each file:
 
  $ aws s3 cp <local_file> s3://net-mozaws-prod-delivery-contrib/pub/webtools/
 
The file can then be accessed by the general public at the same URL as before (over https only):
 
  https://ftp.mozilla.org/pub/mozilla.org/webtools/<file>
 
As a shortcut to copy all of the gz files, one after the other:
 
  $ for i in `ls *.gz`; do aws s3 cp $i s3://net-mozaws-prod-delivery-contrib/pub/webtools/; done
 
To remove a file from S3:
 
  $ aws s3 rm s3://net-mozaws-prod-delivery-contrib/pub/webtools/<remote_file>
 
To list the current files in S3:


Remember to fix the bugzilla-LATEST and bugzilla-STABLE symlinks, if necessary.
  $ aws s3 ls s3://net-mozaws-prod-delivery-contrib/pub/webtools


Also verify that the uploaded files are world readable so that downloads will work properly.
To copy a file on S3 to another name. This needs to be done to mimic the old symlinks for bugzilla-STABLE.tar.gz and bugzilla-LATEST.tar.gz:
 
  $ aws s3 cp s3://net-mozaws-prod-delivery-contrib/pub/webtools/<src_file> s3://net-mozaws-prod-delivery-contrib/pub/webtools/<dest_file>


=== Check-In the Website Updates ===
=== Check-In the Website Updates ===
Line 245: Line 245:


Usually, we GPG sign the Security Advisory with a key that has its public half available from either public keyservers or the bugzilla.org website.
Usually, we GPG sign the Security Advisory with a key that has its public half available from either public keyservers or the bugzilla.org website.
Summary (List the affected versions, not the fixed ones):
  Security advisory for Bugzilla 5.0, 4.4.9, and 4.2.14


The Security Advisory is sent to:
The Security Advisory is sent to:


* BugTraq
* [http://www.securityfocus.com/archive/post/1 BugTraq]
* announce@bugzilla.org
* announce@bugzilla.org
* support-bugzilla@lists.mozilla.org
* support-bugzilla@lists.mozilla.org
Line 258: Line 262:
This is the Release Announcement that you created on the bug that you filed.
This is the Release Announcement that you created on the bug that you filed.


Make sure that you put [ANN] at the beginning of the Subject line.
Make sure that you put [ANN] at the beginning of the Subject line. List the fixed versions.
 
  [ANN] Release of Bugzilla 5.0.1, 4.4.10, and 4.2.15


Send it to:
Send it to:
Line 267: Line 273:
Once again, send each as a separate email.
Once again, send each as a separate email.


=== Update updates.bugzlla.org ===
=== Update updates.bugzilla.org ===


Update bugzilla-update.xml on landfill so that the notification system will detect new releases.
Update bugzilla-update.xml on updates.bugzilla.org so that the notification system will detect new releases.


   ssh dlawrence@updates.mozilla.org
   ssh dlawrence@updates.bugzilla.org
   sudo bash
   sudo bash
   vi /var/www/html/bugzilla-update.xml
   vi /var/www/html/bugzilla-update.xml
Line 282: Line 288:
* Unlock the Security Bugs. Just remove them from the bugzilla-security group
* Unlock the Security Bugs. Just remove them from the bugzilla-security group
* Update the VERSION number in Bugzilla/Constants.pm on each branch, to have a "+" after it.
* Update the VERSION number in Bugzilla/Constants.pm on each branch, to have a "+" after it.
* Update topic on the [irc://irc.mozilla.org/bugzilla #bugzilla] IRC channel on irc.mozilla.org to indicate latest released versions (and note any new EOL versions).


[[category:Bugzilla]]
[[category:Bugzilla]]
DaveLawrence
637

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1029674...1189163"