Re: [Xen-devel] A document for Xen release management

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Jul 17, 2017 at 06:58:27PM +0200, Juergen Gross wrote:
> On 17/07/17 17:09, Wei Liu wrote:
> > 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
> 
> signing
> 

Fixed.

And I also realised I shouldn't have written "company" because I don't
want to imply one has to be employed by a company to become RM.

> > 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
> 
> coordinating
> 

Fixed.

> > 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.
> 
> To which 1.? There are plenty to choose from. :-D

LOL.

The first "1.". This is a markdown feature I abuse so that I don't have
to remember writing the correct numbers.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel