A document for Xen release management

A document for Xen release management

[Wei Liu]

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.

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

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

Re: A document for Xen release management

[Juergen Gross]

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@citrix.com>>
> % Revision 1
> 
> # Motivation
> 
> Over the years we have had different people from different company signning

signing

> 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

> 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

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

use other item numbers than only 1. :-)

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


Thanks,

Juergen

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

Re: A document for Xen release management

[Wei Liu]

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@citrix.com>>
> > % 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@lists.xen.org
https://lists.xen.org/xen-devel

Re: A document for Xen release management

[Lars Kurth]

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@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.
>
>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@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

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

Re: A document for Xen release management

[Ian Jackson]

Wei Liu writes ("A document for Xen release management"):
> When you think all pending issues are fixed and Xen is ready to be released
> from the last RC:

Mostly LGTM.  Thanks!

[Items numbered in quoted text so I can refer to them.]

> 1. Send out commit moratorium emails to committers@.
> 
> 2. 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.
> 
> 3. 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.
> 
> 4. Ask the Release Technician to tag the trees and make the tarball. Ask the
> Community Manager to update relevant web assets.
> 
> 5. Give the PR Personnel signal to proceed. Cooridinate with him / her on the
> public annoucement.

It is OK to make the tarball after giving PR go-ahead.  So I suggest

 3. Select the release date.

 4. Obtain a formal go-ahead from
      - the Community Manager
      - the Release Technician: ask them to dry-run their checklist
        and confirm everything is OK.

 5. Give PR Personnel go-ahead, and instruct Technician to make
    release deliverables.  (Release deliverables - tags and
    tarballs - will usually be in place the day before the release.)

Ian.

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

Re: A document for Xen release management

[Lars Kurth]

On 17/07/2017, 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.

Just to x-ref, see the notes from the meeting at
https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#0
1645
I think I ought to go through the document when the next version is in
place and check, whether something has been missed

Lars
>

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

Re: A document for Xen release management

[Julien Grall]

Hi Wei,

Thank you for writing down the document :).

On 17/07/17 16: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@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.

Do we have a document detailing the release cycle (e.g last posting 
date, hard code freeze...)? If not, would it be worth describing the 
current cut-off scheme here?

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

s/doens't/doesn't/

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

s/corrdinating/coordinating/

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

I would also add a paragraph to send remainder a week before at least 
and "Last posting date" and maybe the "Hard code freeze"?

How about:

"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. Reminder should also be sent a week before important 
cut-off date (e.g last posting date, hard code freeze). Please consider 
adding a recurring even 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

s/Cooridinate/Coordinate/

> public annoucement.

s/annoucement/announcement/

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

s/contigencies/contingencies/

> 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

s/corrdinate/coordinate/

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

I would consider to add the templates for "Development update" and maybe 
the script?

## Development update e-mails

This email only tracks big items for xen.git tree. Please reply for 
items you woulk like to see in $RELEASE_VERSION so that people have an 
idea what is going on and prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release twice a
year. The upcoming $RELEASE_VERSION timeline are as followed:

* Last posting date: $RELEASE_CUTOFF
* Hard code freeze: $RELEASE_FREEZE
* RC1: TBD
* Release: $RELEASE_DATE

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into $RELEASE_VERSION must be posted no later than the 
last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

We recently introduced a jira instance to track all the tasks (not only 
big) for the project. See: 
https://xenproject.atlassian.net/projects/XEN/issues.

Most of the tasks tracked by this e-mail also have a corresponding jira 
task referred by XEN-N.

I have started to include the version number of series associated to 
each feature. Can each owner send an update on the version number if the 
series was posted upstream?

= Projects =

Cheers,

-- 
Julien Grall

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

Re: A document for Xen release management

[Wei Liu]

On Tue, Jul 18, 2017 at 01:45:45PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> Thank you for writing down the document :).
> 
> On 17/07/17 16: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@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.
> 
> Do we have a document detailing the release cycle (e.g last posting date,
> hard code freeze...)? If not, would it be worth describing the current
> cut-off scheme here?

Sure.

[...]
> > 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.
> 
> I would also add a paragraph to send remainder a week before at least and
> "Last posting date" and maybe the "Hard code freeze"?
> 
> How about:
> 
> "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. Reminder should also be sent a week before important cut-off date
> (e.g last posting date, hard code freeze). Please consider adding a
> recurring even to your calendar.".
> 

SGTM.

[...]
> > # 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
> 
> I would consider to add the templates for "Development update" and maybe the
> script?
> 

Yeah, just paste in a stripped down version of the script you use here.

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

Re: A document for Xen release management

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 10902 bytes --]

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 <https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.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=people/larsk/xen-release-scripts.git <http://xenbits.xenproject.org/gitweb/?p=people/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 <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)


[-- Attachment #1.2: Type: text/html, Size: 14817 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: A document for Xen release management

[Wei Liu]

On Mon, Jul 24, 2017 at 11:50:37AM +0100, Lars Kurth wrote:
> 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 <https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.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"

Hmm... let's make these more obvious then.

> 
> > 
> > 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). 
> 

Yes, I think that would be good.

> > 
> > 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=people/larsk/xen-release-scripts.git <http://xenbits.xenproject.org/gitweb/?p=people/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
> <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

How much time would be considered typical?

I'm not sure the steps involved to get PR done. Maybe you can clarify in
the section you volunteered to write.  And then, we can define what RM
needs to do based on that.

> 
> 
> > 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, ...
> 

The most valuable thing to hand over is the script to generate emails,
which we already planned to include in this file.

I think mentioning various creation is good.

> > # 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)

OK.

> 

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