From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: A document for Xen release management Date: Mon, 24 Jul 2017 11:50:37 +0100 Message-ID: <8B73093B-B763-430F-896C-544D2EE7EE5B@gmail.com> References: <20170717150941.23mxd3iemcp22xw5@citrix.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: multipart/mixed; boundary="===============6082948148941533688==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dZawk-00037U-VP for xen-devel@lists.xenproject.org; Mon, 24 Jul 2017 10:50:43 +0000 Received: by mail-wm0-f65.google.com with SMTP id q189so930014wmd.0 for ; Mon, 24 Jul 2017 03:50:40 -0700 (PDT) In-Reply-To: <20170717150941.23mxd3iemcp22xw5@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Wei Liu Cc: Juergen Gross , Lars Kurth , Julien Grall , Committers , xen-devel List-Id: xen-devel@lists.xenproject.org --===============6082948148941533688== Content-Type: multipart/alternative; boundary="Apple-Mail=_BAAF52B3-DAA1-4731-8E89-B0EF7469DE2F" --Apple-Mail=_BAAF52B3-DAA1-4731-8E89-B0EF7469DE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I went over this with a few of the actions from = https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#= 01645 = Lars/Wei/Julien=20 A1 ACTION to write "standard e-mail templates for common stuff", rather = than re-doing these every single time Ian release manager file=20 A2 ACTION : Clean up release technician checklist after we have the how = to be * Add hand-over of tasks for Release Manager responsibility to the "how = to be release manager file" A3 ACTION: Additional stuff to add to the templates/RM guide A3.1: Add clear reminders in particular at the beginning of a release = into e-mail templates: such as put dates X,Y, Z in your calendar add to = checklist and templates A3.2: Communicate better when tree is open again A3.3: Release manager can say "not releasing now" because of too many = bugs, "until someone fixes these". "no more patches until XYZ" Looking through it, I am not sure whether A3.2 and 3.3 are covered. Lars > On 17 Jul 2017, at 16:09, Wei Liu wrote: >=20 > It is agreed during the summit we should write down such document. = Here > is my attempt of doing so. >=20 > We should probably commit something like this into xen.git so that it > gets updated regularly. >=20 > Comments are welcome. >=20 > ----- >=20 > % Xen Release Management > % Wei Liu <> > % Revision 1 >=20 > # Motivation >=20 > 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. >=20 > 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. >=20 > # Xen release cycle >=20 > 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.=20 >=20 > 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. >=20 > During development period, contributors submit patches to be reviewed = and > committed into xen.git. >=20 > 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. >=20 > # The different roles in a Xen release >=20 > ## Release Manager >=20 > 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. >=20 > 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. >=20 > 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. >=20 > ## Maintainers >=20 > 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. >=20 > ## Committers >=20 > 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. >=20 > ## Contributors >=20 > 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. >=20 > ## The Security Team >=20 > 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. >=20 > ## The Release Technician >=20 > 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. >=20 > ## The Community Manager >=20 > 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. >=20 > ## The PR Personnel >=20 > 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. >=20 > # What happens during a release >=20 > ## Development period >=20 > 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. >=20 > Occasionally check the status of the xen-unstable branch, make sure it = gets > timely pushes to master. >=20 > ## Freeze period >=20 > Before or at very early stage of the freeze period, agree with the = Community > Manager a schedule for RC test days. >=20 > Once the freeze starts, the ownership of xen-unstable branch = automatically > transfers to the Release Manager. >=20 > Here is a list of things to do for making RCs: >=20 > 1. Check the status of the tree. Ask the Release Technician to make an = RC if the tree is good. >=20 > 1. Send an email to xen-devel, xen-users and xen-announce to announce = the RC. >=20 > 1. Branch and / or reopen the tree for further feature submission if = appropriate. >=20 > 1. Collect and track any issues reported, determine their severity, = prod relevant developers and maintainers to fix the issues. >=20 > 1. When patches to fix issues are posted, determine if the patches are = good to be included. >=20 > 1. Go back to 1. >=20 > 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. >=20 > 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. Does it make sense to move this into a separate section, or have a = separate section which list the key steps? If so, I am happy to pull = this together. Primarily I tend to drive the PR angle with Zibby and = would be happy to create a checklist. The Release Manager's role here is = one of providing input, but can (if desired) be more high profile (e.g. = quotes in releases).=20 >=20 > When you think all pending issues are fixed and Xen is ready to be = released > from the last RC: >=20 > 1. Send out commit moratorium emails to committers@. >=20 > 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. >=20 > 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. I think double checking is good. If = http://xenbits.xenproject.org/gitweb/?p=3Dpeople/larsk/xen-release-scripts= .git = are deemed to be fit for purpose, we should probably refer to = these > 1. Ask the Release Technician to tag the trees and make the tarball. = Ask the > Community Manager to update relevant web assets. Add: 1. Check with relevant stake-holders (typically community manager) = whether wiki documentation and PR is in good shape (for an example see = https://wiki.xenproject.org/wiki/Category:Xen_4.9 = ) >=20 > 1. Give the PR Personnel signal to proceed. Cooridinate with him / her = on the > public annoucement. Typically we will need a bit of lead-time here to ensure that everything = is in place > 1. Make the announcement on various mailing list, publish the blog = post. >=20 > 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. >=20 >=20 There should probably be a section along the lines of (for A2) ## Hand over of Release Manager Responsibility Probably this is an area where Wei, George, Konrad and Julien have = experience. This should include a list of systems a Release Manager should be signed = up to, such as blog account, xen-announce, ... > # Email templates >=20 > ## RC emails >=20 >> Hi all, >>=20 >> Xen X.Y rcZ is tagged. You can check that out from xen.git: >>=20 >> git://xenbits.xen.org/xen.git X.Y.0-rcZ >>=20 >> 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.g= z >>=20 >> And the signature is at: >> = https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.g= z.sig >>=20 >> Please send bug reports and test reports to = xen-devel@lists.xenproject.org. >> When sending bug reports, please CC relevant maintainers and me >> (abc@xyz.com). >>=20 >> As a reminder, there will be another Xen Test Day.=20 >>=20 >> See instructions on: URL_TO_TEST_INSTRUCTIONS We should probably have mail templates for the specific stages of the = process, which can then include reminders to add calendar entries (see = A3.1) --Apple-Mail=_BAAF52B3-DAA1-4731-8E89-B0EF7469DE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

I = went over this with a few of the actions from https://lists.xenproject.org/archives/html/xen-devel/2017-07/th= reads.html#01645

Lars/Wei/Julien 
A1 = ACTION to write "standard e-mail templates for common stuff", rather = than re-doing these every single time
Ian release = manager file 

A2 ACTION : Clean up release technician checklist after we = have the how to be
* Add hand-over = of tasks for Release Manager responsibility to the "how to be release = manager file"

A3= ACTION: Additional stuff to add to the templates/RM guide
A3.1: Add clear reminders in particular at the beginning of a = release into e-mail templates: such as put dates X,Y, Z in your calendar = add to checklist and templates
A3.2: Communicate = better when tree is open again
A3.3: Release = manager can say "not releasing now" because of too many bugs, "until = someone fixes these". "no more patches until XYZ"
Looking through it, I am not sure = whether A3.2 and 3.3 are covered.

Lars

On 17 Jul 2017, at 16:09, Wei Liu <wei.liu2@citrix.com>= 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@citrix.com>>
% 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.

Does it = make sense to move this into a separate section, or have a separate = section which list the key steps? If so, I am happy to pull this = together. Primarily I tend to drive the PR angle with Zibby and would be = happy to create a checklist. The Release Manager's role here is one of = providing input, but can (if desired) be more high profile (e.g. quotes = in releases). 


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.

I think double checking is good. If http://xenbits.xenproject.org/gitweb/?p=3Dpeople/larsk/xen-rele= ase-scripts.git are deemed to be fit for purpose, we should = probably refer to these

1. Ask the Release = Technician to tag the trees and make the tarball. Ask the
Community Manager to update relevant web assets.

Add:

1. Check with = relevant stake-holders (typically community manager) whether wiki = documentation and PR is in good shape (for an example see https://wiki.xenproject.org/wiki/Category:Xen_4.9)


1. Give the PR Personnel signal to proceed. = Cooridinate with him / her on the
public annoucement.

Typically = we will need a bit of lead-time here to ensure that everything is in = place


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.



There = should probably be a section along the lines of (for A2)

## Hand over of Release Manager = Responsibility

Probably this is an = area where Wei, George, Konrad and Julien have experience.

This should include a list of systems a Release = Manager should be signed up to, such as blog account, xen-announce, = ...

# 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@lists.xenproject.org.
When = sending bug reports, please CC relevant maintainers and me
(abc@xyz.com).

As a reminder, = there will be another Xen Test Day.

See = instructions on: = URL_TO_TEST_INSTRUCTIONS

We should probably have mail templates for the = specific stages of the process, which can then include reminders to add = calendar entries (see A3.1)

= --Apple-Mail=_BAAF52B3-DAA1-4731-8E89-B0EF7469DE2F-- --===============6082948148941533688== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6082948148941533688==--