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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

I added Jan because I think we should probably add a section for point
releases, which I assume would be a subset of the steps in this document
Lars

I will post the notes of the design session also. I am doing the ones
first that I moderated and where I took notes in handwriting and/or photos
of whiteboard discussions first though, such that I don't miss too much
stuff

Lars
 
On 17/07/2017, 16:09, "Wei Liu" <wei.liu2@xxxxxxxxxx> 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
>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.
>
>When you think all pending issues are fixed and Xen is ready to be
>released
>from the last RC:
>
>1. Send out commit moratorium emails to committers@.
>
>1. Check all the trees (mini-os, qemu-trad, qemu-xen, seabios, ovmf etc).
>They have the correct commits and all security patches applied. There
>will be
>tools provided.
>
>1. Ask the Community Manager and Release Technician to double-check all
>security patches have been applied. If not, apply them, arrange another RC
>and restart this checklist.
>
>1. Ask the Release Technician to tag the trees and make the tarball. Ask
>the
>Community Manager to update relevant web assets.
>
>1. Give the PR Personnel signal to proceed. Cooridinate with him / her on
>the
>public annoucement.
>
>1. Make the announcement on various mailing list, publish the blog post.
>
>Allow for contigencies. It is not uncommon that some last minute
>(security or
>not) bugs are discovered. To provide a fix takes time, the test of the fix
>will also take time. Allow for at least 1 week from getting a fix to
>getting
>a push. For security bugs, corrdinate with the Security Team to adjust the
>dates according to our security policy.
>
>
># Email templates
>
>## RC emails
>
>> Hi all,
>> 
>> Xen X.Y rcZ is tagged. You can check that out from xen.git:
>> 
>> git://xenbits.xen.org/xen.git X.Y.0-rcZ
>> 
>> For your convenience there is also a tarball at:
>> 
>>https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.
>>gz
>> 
>> And the signature is at:
>> 
>>https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.
>>gz.sig
>> 
>> Please send bug reports and test reports to
>>xen-devel@xxxxxxxxxxxxxxxxxxxx.
>> When sending bug reports, please CC relevant maintainers and me
>> (abc@xxxxxxx).
>> 
>> As a reminder, there will be another Xen Test Day.
>>
>> See instructions on: URL_TO_TEST_INSTRUCTIONS

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