It is agreed during the summit we should write down such document. Here
is my attempt of doing so.
We should probably commit something like this into xen.git so that it
gets updated regularly.
Comments are welcome.
-----
% Xen Release Management
% Wei Liu <<
wei.liu2@xxxxxxxxxx>>
% Revision 1
# Motivation
Over the years we have had different people from different company signning
up as the Release Manager of Xen. It would be rather wasteful if every new
Release Manager has to go over everything and tripped over by the same
mistakes again and again.
This file intends to document the process of managing a Xen release. It is
mainly written for Release Manager, but other roles (contributors,
maintainers and committers) are also encouraged to read this document, so
that they can have an idea what to expect from the Release Manager.
# Xen release cycle
The Xen hypervisor project now releases twice a year, at the beginning of
June and the beginning of December. The actual release date depends on a lot
of factors.
We can roughly divide one release into two periods. The development period
and the freeze period. The former is 4 months long and the latter is about 2
months long.
During development period, contributors submit patches to be reviewed and
committed into xen.git.
During freeze period, the tree is closed for new features. Only bug fixes are
accepted. This period can be shorter or longer than 2 months. If it ends up
longer than 2 months, it eats into the next development period.
# The different roles in a Xen release
## Release Manager
A trusted developer in the community that owns the release process. The major
goal of the Release Manager is to make sure a Xen release has high quality
and doens't slip too much.
The Release Manager will not see much workload during development period, but
expects to see increasing workload during the freeze period until the final
release. He or she is expected to keep track of issues, arrange RCs,
negotiate with relevant stakeholders, balance the need from various parties
and make difficult decisions when necessary.
The Release Manager essentially owns xen-unstable branch during the freeze
period. The committers will act on the wishes of the Release Manager during
that time.
## Maintainers
A group of trusted developers who are responsible for certain components in
xen.git. They are expected to respond to patches / questions with regard to
their components in a timely manner, especially during the freeze period.
## Committers
A group of trusted maintainers who can commit to xen.git. During the
development window they normally push things as they see fit. During the
freeze period they transfer xen-unstable branch ownership and act on the
wishes of the Release Manager. That normally means they need to have an
Release Ack in order to push a patch.
## Contributors
Contributors are also expected to respond quickly to any issues regarding the
code they submitted during development period. Failing that, the Release
Manager might decide to revert the changes, declare feature unsupported or
take any action he / she deems appropriate.
## The Security Team
The Security Team operates independently. The visibility might be rather
limited due to the sensitive nature of security work. The best action the
Release Manager can take is to set aside some time for potential security
issues to be fixed.
## The Release Technician
The Release Technician is the person who tags various trees, prepares tarball
etc. He or she acts on the wishes of the Release Manager. Please make sure
the communication is as clear as it can be.
## The Community Manager
The Community Manager owns
xenproject.org infrastructure. He or she is
responsible for updating various web archives, updating wiki pages and
coordinating with the PR Personnel.
## The PR Personnel
They are responsible for corrdinating with external reporters to publish Xen
release announcement. The Release Manager should be absolutely sure the
release is going out on a particular date before giving them the signal to
proceed, because there is a point of no return once they schedule a date with
external reporters.
# What happens during a release
## Development period
Send out monthly update email. The email contains the timeline of the
release, the major work items and any other information the Release Manager
sees fit. Please consider adding a recurring event to your calendar.
Occasionally check the status of the xen-unstable branch, make sure it gets
timely pushes to master.
## Freeze period
Before or at very early stage of the freeze period, agree with the Community
Manager a schedule for RC test days.
Once the freeze starts, the ownership of xen-unstable branch automatically
transfers to the Release Manager.
Here is a list of things to do for making RCs:
1. Check the status of the tree. Ask the Release Technician to make an RC if the tree is good.
1. Send an email to xen-devel, xen-users and xen-announce to announce the RC.
1. Branch and / or reopen the tree for further feature submission if appropriate.
1. Collect and track any issues reported, determine their severity, prod relevant developers and maintainers to fix the issues.
1. When patches to fix issues are posted, determine if the patches are good to be included.
1. Go back to 1.
It is normally OK in the early RCs that you hand back xen-unstable branch to
committers so that they can commit bug fixes at will. As we approach late
RCs, the standard for accepting a patch will get higher and higher. Please
communicate clearly when committers can commit at will and when formal
Release Ack is needed.
At the same time, work with the Community Manager, PR Personnel and
Contributors to gather a list of features for the release. Discuss the
support status of new features with stakeholders. Help prepare the press
release, write a blog post for the release.
