4:05 a.m.
Hi,
while we're near to release 3.5.0 I would like to start the discussion on the release
process for 3.5.z and 3.6.0.
The reference page for the release process has been last updated 2 years ago and is not
reflecting the way we're managing the releases anymore.
In order to start the discussion here's what we are currently doing:
= oVirt maintenance releases =
* After a new 3.y.0 release, maintenance releases are scheduled every month until a new
3.y+1.0 release is published.
* After first 3.y.0 release candidate is published a new release management wiki page is
created (see http://www.ovirt.org/OVirt_3.4.z_release-management)
* For each 3.y.z release, the release management page is updated
** Defining the schedule for RC and GA date
** Pointing to the new release note page to be created (see
http://www.ovirt.org/OVirt_3.4.4_Release_Notes)
** Pointing to a testing page to be created (see
http://www.ovirt.org/Testing/oVirt_3.4.4_Testing)
** Pointing to a blocker bug to be created (see http://bugzilla.redhat.com/1118689)
* Weekly status email are sent to users and devel lists
* QA page is updated with pointers to the new release (see
http://www.ovirt.org/OVirt_Quality_Assurance)
* Release manager update the release notes pages starting from RC
Usually RC date is scheduled one week before GA.
RC releases are created by taking the latest nightly snapshot available after verifying
that the build passes basic sanity test and repository closure.
A new stabilization branch is created with the same git hash used for building the
snapshot.
Between RC and GA release criteria are tested on the RC and if the release met the
criteria a GA release will be built just updating the versioning
code to drop master, git hash and timestamp suffix from tarballs and rpms.
A new RC will be created and GA postponed by one week if release criteria are not met.
= oVirt Release Process =
* After a new 3.y.0 release, a new 3.y+1.0 release is tentatively scheduled after 6
months.
* A new release management page is created (see
http://www.ovirt.org/OVirt_3.5_release-management)
* A new tracker bug is created (see http://bugzilla.redhat.com/1073943)
* A discussion is started on devel and users mailing list gathering idea for next release
features
* Teams prepare a list of accepted features collecting / creating bug tracker, devel
owner, qa owner, feature page for each of them
* Several presentations are scheduled by the teams presenting the accepted features
* An alpha release is scheduled 4 months before GA
* Feature freeze is scheduled 3 months before GA
* A beta release is scheduled 2 months before GA, git tree is branched for stabilization
* A release candidate is scheduled 1 month before GA
* Weekly status email are sent starting 3 weeks before alpha release.
* Test days are scheduled after every milestone release
* Release manager update the release notes pages starting from Alpha
All milestones releases are created by taking the latest nightly snapshot available after
verifying that the build passes basic sanity test and
repository closure.
RC will be postponed until all known blockers are fixed
Between RC and GA release criteria are tested on the RC and if the release met the
criteria a GA release will be built just updating the versioning
code to drop master, git hash and timestamp suffix from tarballs and rpms.
A new RC will be created and GA postponed by one week if release criteria are not met.
[[Category:Release management]]
What I think we're missing / doing wrong:
* A discussion about release criteria *after* accepted features list is ready
* A clear schedule like http://fedoraproject.org/wiki/Releases/21/Schedule
* A clear feature freeze policy like https://fedoraproject.org/wiki/Changes_Freeze_Policy
* A clear policy about changes we must allow and not allow between RC and GA
* Alpha release should come after feature freeze
* A string freeze schedule, allowing translators to have enough time to translate new
strings
* Maintainers should pay more attention to release notes and test day pages
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com