Processes

Differences between revisions 1 and 22 (spanning 21 versions)
Revision 1 as of 2011-09-19 15:42:59
Size: 3260
Editor: charlie-tca
Comment: 2011-09-19; CharlieKravetz; a process/checklist to assist in getting all the items done for Xubuntu releases
Revision 22 as of 2013-10-19 01:23:11
Size: 6155
Editor: knome
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#title Xubuntu Release Process #title Xubuntu Processes
Line 5: Line 5:
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| == Release Cycle ==
Line 7: Line 7:
||<tablestyle="width: 95%;" style="border: none;" -5> The release cycle consists of 5 more or less overlapping stages, which are: ||
||<style="width: 20%; border: none; padding-top: 5px; border-top-left-radius: 10px; border-bottom-left-radius: 10px;" #d1e0f0 :> [[#Planning|Planning]] ||<style="width: 20%; border: none; padding-top: 5px;" #b7d1ea :> [[#Developing|Developing]] ||<style="width: 20%; border: none; padding-top: 5px;" #d1e0f0 :> [[#Testing|Testing]] ||<style="width: 20%; border: none; padding-top: 5px;" #b7d1ea :> [[#Releasing|Releasing]] ||<style="width: 20%; border: none; padding-top: 5px; border-top-right-radius: 10px; border-bottom-right-radius: 10px;" #d1e0f0 :> [[#Maintaining|Maintaining]] ||
Line 8: Line 10:
To be carried out by: The Xubuntu Release Manager, with support from the Xubuntu Development Team and advice from the [[https://launchpad.net/~ubuntu-release|Ubuntu release team]] === Planning ===
Line 10: Line 12:
Goals: Planning the release is conducted in three phases:
 * Brainstorming
 * Approving blueprints
 * Finalizing specifications
Line 12: Line 17:
 * Ensure that all ISOs are suitable for release.
 * This process should apply to alphas, betas, [[ReleaseCandidate|ReleaseCandidates]], final releases, and milestones.
 * Ship it!
In the brainstorming phase the contributors determine what they would like to work on during the release cycle, including proposals for changes in default applications. Anybody can items to the list. Settling on the goals in advance will make planning, focusing and estimating the likelihood for the features to be implemented easier.
Line 16: Line 19:
== T minus 14 days == After the brainstorming is over and before or on the Feature Definition Freeze day, the Xubuntu team will approve or reject the proposed blueprints. Any items with no assignee or rationale will be automatically rejected, but having them will not guarantee that the blueprint is approved. Other criteria include, but are not limited to: likelihood of getting the feature implemented, maintenance weight in the future, possible stability issues, influence on other blueprints, et cetera. The approved blueprints compose the roadmap for the release being developed.
Line 18: Line 21:
 1. Forward notifications of milestone freeze to xubuntu-devel@lists.ubuntu.com mailing list.
 1. Insure freeze times are posted in #xubuntu-devel and xubuntu-devel@lists.ubuntu.com mailing list.
 1. Freeze Day - notify developers of freeze and change topic in #xubuntu-devel.
After blueprints are approved, they should be finalized and detailed specifications should be written. These specifications should document the proposed changes and help guide the implementation. The Ubuntu freezes define the deadlines for implementation.
Line 22: Line 23:
== T minus 7 days == === Developing ===
Line 24: Line 25:
 1. Request Xubuntu developers availability for milestone testing.
 1. Review [[https://wiki.ubuntu.com/Xubuntu/Testing | testing pages]] to insure they are up to date.
 1. Remind project lead to begin preparing release notes.
In addition to implementing the features and/or improvements set in the roadmap, there are a number of tasks which will occur during each release cycle:
 * Xubuntu packages will be synced or merged with Debian as appropriate
 * Bugs reported by users will be reviewed, fixed, and/or passed upstream
 * Attempt to reduce our delta by pushing appropriate patches upstream
 * Evaluate the seeds to ensure we are shipping the optimal software
 * Work on improving and updating the Xubuntu documentation
Line 28: Line 32:
== T minus 5 days == === Testing ===
Line 30: Line 34:
 * Testing should smoketest the images to insure they install. Throughout the release cycle and even more so nearing the end, we will test Xubuntu to ensure that Xubuntu is a quality product that we are proud of. This includes testing that changes we have been making meet the release goals, work as expected, and do not cause regressions. Any tests run should be reported to the QA trackers. To read more about conducting tests and reporting them, refer to TESTING_WIKI.
Line 32: Line 36:
== T minus 3 days == The Xubuntu testing team will help ensure that when milestone ISOs are released, all tests are completed and results reported to the tracker. Xubuntu testers will also test the daily builds, upgrading through supported release paths and running the development version of Xubuntu on a daily basis to help detect problems. The most important goals for testing the daily images are simply to find as many bugs as possible and report them with sufficient detail to the tracker along with the ISO testing result.
Line 34: Line 38:
 1. Testing begins on the images available.
  * For alpha images, use the [[https://wiki.ubuntu.com/Xubuntu/Testing/TestingInfo/Short | short tests]].
  * For beta, rc, and final images, use the [[https://wiki.ubuntu.com/Xubuntu/Testing/TestingInfo/Long | long tests]].
  * All tests are recorded/tracked using the Ubuntu QA [[http://iso.qa.ubuntu.com/qatracker/build/xubuntu/all | ISO tracker]].
 1. Coordinate all testing with Ubuntu QA in #ubuntu-testing.
 1. Start the news article for the release; this is to be published on [[http://xubuntu.org | the website]] at the time of the release.
The Xubuntu testing team also helps test applications that are included in Xubuntu and make sure sufficient amount of testing is made and results reported to the packages tracker. Additional testing should be conducted when a new default application is to be included in the next Xubuntu release.
Line 41: Line 40:
== T minus 1 day == === Releasing ===
Line 43: Line 42:
 1. Add release notes to the wiki.
  * Alpha notes are combined with Ubuntu release notes at https://wiki.ubuntu.com/ReleaseName/TechnicalOverview .
  * Beta and rc notes can be combined as alpha or, if significant changes were made should be separate under https://wiki.ubuntu.com/Xubuntu/ReleaseName/Milestone (example: https://wiki.ubuntu.com/Xubuntu/LucidLynx/Final).
When it comes time to deploy a release (both milestones and final) several conditions must be met:
 * Appropriate testing has been done on the image
 * There are no known bugs which cause data loss or damage to hardware
 * The image must not be oversized
 * Xubuntu must be of sufficient quality that it would not damage Xubuntu's, Ubuntu's, or any of the other flavors' reputation/image.
Line 47: Line 48:
== Release Day == When a release is made, the Xubuntu Release Team must follow the release process specified below. The release process ensures that the new release has sufficient release notes and release announcement and that all release-specific communication is updated to inform about the new release. Where needed, advice from the [[LP~ubuntu-release|Ubuntu release team]] should be asked for.
Line 49: Line 50:
 1. Review the Technical Overview/Release Notes to insure everything is accurate.
 1. Monitor for release announcement and PASS IT ON when announced.
  * Publish news on the Xubuntu website.
  * For the final release, insure the website download page is updated for the new release.
 1. Review bugs to insure all bugs found during testing are listed at https://wiki.ubuntu.com/Xubuntu/Bugs/ReleaseName .
 1. Update the [[https://wiki.ubuntu.com/Xubuntu/TeamReports | Team Report]].
 1. Add milestone review to [[https://wiki.ubuntu.com/Xubuntu/Meetings | meeting agenda]].
  * Reviewing as soon as possible helps to learn what we could have done better.
  * This is also a great time to congratulate the team for a job well done.
''' The Xubuntu release process '''
Line 59: Line 52:
== T plus 7 days == ||<^> ''' 14 days before release ''' || Notifications of freezes <<BR>> Reminder to update the website FAQ (final release only) ||
||<^> ''' 7 days before release ''' || Gather people for milestone testing <<BR>> Start preparing release notes and release announcement ||
||<^> ''' 5 days before release ''' || Smoketest images ||
||<^> ''' 3 days before release ''' || Start milestone testing ||
||<^> ''' 1 day before release ''' || Review release notes ||
||<^> ''' Release day ''' || Mark images ready on the ISO tracker <<BR>> Publish release announcement and notes <<BR>> Update the website, IRC channel topics and social media outlets with new release information ||
||<^> ''' After release ''' || Update the developer wiki to next release (final release only) <<BR>> Review and update this page ||
Line 61: Line 60:
 * Review this page and update it as needed for the next milestone/release period.
 * Reviewing as soon as possible helps keep this as up to date as possible.
=== Maintaining ===

After a release is made, bugs and problems are bound to be reported. The period between the release and the start of the next release cycle is the optimal time to perform Stable Release Updates (SRU) for major bugs as long as developers do not forget to fix the issue in the next release as well, once the repository opens. Once the next release cycle has started, primary focus will be on the next release and the severity/importance of the SRU candidates will be more important when it comes to deciding whether an SRU will be performed or not.

Release Cycle

The release cycle consists of 5 more or less overlapping stages, which are:

Planning

Developing

Testing

Releasing

Maintaining

Planning

Planning the release is conducted in three phases:

  • Brainstorming
  • Approving blueprints
  • Finalizing specifications

In the brainstorming phase the contributors determine what they would like to work on during the release cycle, including proposals for changes in default applications. Anybody can items to the list. Settling on the goals in advance will make planning, focusing and estimating the likelihood for the features to be implemented easier.

After the brainstorming is over and before or on the Feature Definition Freeze day, the Xubuntu team will approve or reject the proposed blueprints. Any items with no assignee or rationale will be automatically rejected, but having them will not guarantee that the blueprint is approved. Other criteria include, but are not limited to: likelihood of getting the feature implemented, maintenance weight in the future, possible stability issues, influence on other blueprints, et cetera. The approved blueprints compose the roadmap for the release being developed.

After blueprints are approved, they should be finalized and detailed specifications should be written. These specifications should document the proposed changes and help guide the implementation. The Ubuntu freezes define the deadlines for implementation.

Developing

In addition to implementing the features and/or improvements set in the roadmap, there are a number of tasks which will occur during each release cycle:

  • Xubuntu packages will be synced or merged with Debian as appropriate
  • Bugs reported by users will be reviewed, fixed, and/or passed upstream
  • Attempt to reduce our delta by pushing appropriate patches upstream
  • Evaluate the seeds to ensure we are shipping the optimal software
  • Work on improving and updating the Xubuntu documentation

Testing

Throughout the release cycle and even more so nearing the end, we will test Xubuntu to ensure that Xubuntu is a quality product that we are proud of. This includes testing that changes we have been making meet the release goals, work as expected, and do not cause regressions. Any tests run should be reported to the QA trackers. To read more about conducting tests and reporting them, refer to TESTING_WIKI.

The Xubuntu testing team will help ensure that when milestone ISOs are released, all tests are completed and results reported to the tracker. Xubuntu testers will also test the daily builds, upgrading through supported release paths and running the development version of Xubuntu on a daily basis to help detect problems. The most important goals for testing the daily images are simply to find as many bugs as possible and report them with sufficient detail to the tracker along with the ISO testing result.

The Xubuntu testing team also helps test applications that are included in Xubuntu and make sure sufficient amount of testing is made and results reported to the packages tracker. Additional testing should be conducted when a new default application is to be included in the next Xubuntu release.

Releasing

When it comes time to deploy a release (both milestones and final) several conditions must be met:

  • Appropriate testing has been done on the image
  • There are no known bugs which cause data loss or damage to hardware
  • The image must not be oversized
  • Xubuntu must be of sufficient quality that it would not damage Xubuntu's, Ubuntu's, or any of the other flavors' reputation/image.

When a release is made, the Xubuntu Release Team must follow the release process specified below. The release process ensures that the new release has sufficient release notes and release announcement and that all release-specific communication is updated to inform about the new release. Where needed, advice from the Ubuntu release team should be asked for.

The Xubuntu release process

14 days before release

Notifications of freezes
Reminder to update the website FAQ (final release only)

7 days before release

Gather people for milestone testing
Start preparing release notes and release announcement

5 days before release

Smoketest images

3 days before release

Start milestone testing

1 day before release

Review release notes

Release day

Mark images ready on the ISO tracker
Publish release announcement and notes
Update the website, IRC channel topics and social media outlets with new release information

After release

Update the developer wiki to next release (final release only)
Review and update this page

Maintaining

After a release is made, bugs and problems are bound to be reported. The period between the release and the start of the next release cycle is the optimal time to perform Stable Release Updates (SRU) for major bugs as long as developers do not forget to fix the issue in the next release as well, once the repository opens. Once the next release cycle has started, primary focus will be on the next release and the severity/importance of the SRU candidates will be more important when it comes to deciding whether an SRU will be performed or not.

Xubuntu/Processes (last edited 2016-02-16 17:58:09 by knome)