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

2017-07-27 Thread Wei Liu 
On Thu, Jul 27, 2017 at 11:30:11AM +0100, Julien Grall wrote:
> 
> 
> On 25/07/17 14:25, Wei Liu wrote:
> > Hi all
> 
> Hi Wei,
> 
> Sorry for the late reply.
> 
> > ## Script to generate months update emails
> 
> I have an updated script on which include jira ticket, version number:
> 

Merged. Thanks.

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

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

2017-07-27 Thread Julien Grall 


On 25/07/17 14:25, Wei Liu wrote:
> Hi all

Hi Wei,

Sorry for the late reply.

> ## Script to generate months update emails

I have an updated script on which include jira ticket, version number:

#!/bin/bash
# Use ssmtp for simplicity
# ./status-release.sh | formail -f -s /usr/sbin/ssmtp -bm -t

FILE=`mktemp`
cat << EOF > $FILE

== Hypervisor ==

S: Per-cpu tasklet
O: Konrad Rzeszutek Wilk
E: konrad.w...@oracle.com
J: XEN-28

=== x86 ===

=== ARM ===

== Completed ==

S:
EOF


AWK_FILE=`mktemp`
cat << EOF > $AWK_FILE
BEGIN { s2_count = 1;score = ""; emails=1; first_time = 1; subject=""}
/== /  {
if ( subject != "" )  {
if (score != "")
print "* ", subject,  "("score")"
else if (version != "")
print "* ", subject, "("version")";
else
print "* ", subject;
for (i = 1; i <= s2_count; i++) {
if (i in s2)
print " ",s2[i];
}
if (bug != "")
print "  Link: https://bugs.xenproject.org/xen/bug/"bug
if (jira != "")
print "  -  "jira
for (i = 1; i <= count; i++) {
if (i in o)
print "  -", o[i]
}
if (emails)
print ""
first_time = 1;
subject=""
email=""
score=""
bug=""
jira=""
version=""
count = 1;
s2_count = 1;
delete s;
delete s2;
delete o;
delete e;
}
print \$0,"\n"
}
/;/ { };
/S:/{
if ( !first_time )  {
if (score != "")
print "* ", subject,  "("score")"
else if (version != "")
print "* ", subject, "("version")";
else
print "* ", subject
for (i = 1; i <= s2_count; i++) {
if (i in s2)
print " ",s2[i];
}
if (bug != "")
print "  Link: https://bug.xenproject.org/xen/bug/"bug
if (jira != "")
print "  -  "jira
for (i = 1; i <= count; i++) {
if (i in o)
print "  -", o[i]
}
if (emails)
print ""
}
first_time = 0;
sub(\$1, "");
sub(/^[ \t]+/, "");
subject=\$0;
email=""
bug=""
jira=""
count = 1;
s2_count = 1;
delete s;
delete s2;
delete o;
delete e;
score="";
version="";
}
/O:/{ sub(\$1, ""); o[count++]=\$0; };
/S2:/   { sub(\$1, ""); s2[s2_count++]=\$0;};
/E:/{ sub(\$1, ""); sub(/^[ \t]+/, ""); email=\$0; e[emails++]=\$0;};
/P:/{ sub(\$1, ""); sub(/^[ \t]+/, ""); score=\$0; };
/B:/{ sub(\$1, ""); sub(/^[ \t]+/, ""); bug=\$0; };
/J:/{ sub(\$1, ""); sub(/^[ \t]+/, ""); jira=\$0; };
/V:/{ sub(\$1, ""); sub(/^[ \t]+/, ""); version=\$0; };
END {
}
// {  }
EOF
AWK_FILE_EMAIL=`mktemp`
cat << EOF > $AWK_FILE_EMAIL
BEGIN { emails=1;}
/E:/{
sub(\$1, ""); sub(/^[ \t]+/, "");
email=\$0;
for ( i = 1; i <= emails; i++ ) {
if (i in e) {
if (e[i] == email) {
email="";
break;
}
}
}
if (email != "")
e[emails++]=email;
}
END {
printf "Bcc: "
for ( i = 1; i <= emails; i++ )
if (i in e) {
if (i == emails - 1)
printf "<%s>", e[i];
else
printf "<%s>,", e[i];
}
print ""
}
// {  }
EOF

echo "From: $RELEASE_MANAGER_NAME <$RELEASE_MANAGER_MAIL>"
echo "To: xen-de...@lists.xenproject.org"
echo "Cc: $RELEASE_MANAGER_MAIL"
cat $FILE | awk -f $AWK_FILE_EMAIL
rm $AWK_FILE_EMAIL

echo "Subject: Xen $RELEASE_VERSION Development Update"
PRE=`mktemp`
cat << EOF > $PRE

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

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

2017-07-26 Thread Wei Liu 
On Wed, Jul 26, 2017 at 03:31:29PM +0100, Lars Kurth wrote:
> Hi all,
> 
> > On 25 Jul 2017, at 14:25, Wei Liu  wrote:
> > 
> > Hi all
> > 
> > This is v2 of this document.
> > 
> > Lars, please insert your section as you see fit.
> 
> Done + some other minor mods

Merged into my repo.

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

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

2017-07-26 Thread Lars Kurth 
Hi all,

> On 25 Jul 2017, at 14:25, Wei Liu  wrote:
> 
> Hi all
> 
> This is v2 of this document.
> 
> Lars, please insert your section as you see fit.

Done + some other minor mods

> ---8<---
> % Xen Release Management
> % Wei Liu <>
> % Revision 1
> 
> # Motivation
> 
> Over the years we have had different people 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. All feature patches must be committed before a date,
> which is normally called the "cut-off date", after which the freeze period
> starts. There will be a date before which all patches that wish to be merged
> for the release should be posted -- it is normally called the "last posting
> date" and it is normally two weeks before the "cut-off date".
> 
> 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.
> 
> Here is a conjured up example (use cal 2017 to get an idea):
> 
> * Development period: 2017 June 11 - 2017 September 29
>* the "cut-off date" is 2017 September 29
>* the "last posting date" is 2017 September 15
> * Freeze period: 2017 October 2 - 2017 December 7
>* the anticipated release date is 2017 December 7
> 
> # 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 doesn'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 coordinating 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

[Xen-devel] A document for Xen release management, v2

2017-07-25 Thread Wei Liu 
Hi all

This is v2 of this document.

Lars, please insert your section as you see fit.

Wei.

---8<---
% Xen Release Management
% Wei Liu <>
% Revision 1

# Motivation

Over the years we have had different people 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. All feature patches must be committed before a date,
which is normally called the "cut-off date", after which the freeze period
starts. There will be a date before which all patches that wish to be merged
for the release should be posted -- it is normally called the "last posting
date" and it is normally two weeks before the "cut-off date".

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.

Here is a conjured up example (use cal 2017 to get an idea):

* Development period: 2017 June 11 - 2017 September 29
* the "cut-off date" is 2017 September 29
* the "last posting date" is 2017 September 15
* Freeze period: 2017 October 2 - 2017 December 7
* the anticipated release date is 2017 December 7

# 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 doesn'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 coordinating 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. Reminders should also be sent one week before important dates (see
above, "last posting