[PATCH 0/3] Docs: consolidate release related documents

[PATCH 0/3] Docs: consolidate release related documents

[Wei Liu]

Wei Liu (3):
  docs: consolidate release related documents
  docs: add xen-release-management.pandoc
  docs: hook up process/ to build system

 docs/Makefile                                  |   2 +-
 {misc => docs/process}/branching-checklist.txt |   0
 {misc => docs/process}/release-checklist.txt   |   0
 docs/process/xen-release-management.pandoc     | 594 +++++++++++++++++++++++++
 4 files changed, 595 insertions(+), 1 deletion(-)
 rename {misc => docs/process}/branching-checklist.txt (100%)
 rename {misc => docs/process}/release-checklist.txt (100%)
 create mode 100644 docs/process/xen-release-management.pandoc

-- 
2.11.0


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

[PATCH 1/3] docs: consolidate release related documents

[Wei Liu]

Move the existing docs from misc to docs/process.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 {misc => docs/process}/branching-checklist.txt | 0
 {misc => docs/process}/release-checklist.txt   | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename {misc => docs/process}/branching-checklist.txt (100%)
 rename {misc => docs/process}/release-checklist.txt (100%)

diff --git a/misc/branching-checklist.txt b/docs/process/branching-checklist.txt
similarity index 100%
rename from misc/branching-checklist.txt
rename to docs/process/branching-checklist.txt
diff --git a/misc/release-checklist.txt b/docs/process/release-checklist.txt
similarity index 100%
rename from misc/release-checklist.txt
rename to docs/process/release-checklist.txt
-- 
2.11.0


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

[PATCH 2/3] docs: add xen-release-management.pandoc

[Wei Liu]

A document for the release manager.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 docs/process/xen-release-management.pandoc | 594 +++++++++++++++++++++++++++++
 1 file changed, 594 insertions(+)
 create mode 100644 docs/process/xen-release-management.pandoc

diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc
new file mode 100644
index 0000000000..afdf559429
--- /dev/null
+++ b/docs/process/xen-release-management.pandoc
@@ -0,0 +1,594 @@
+% Xen Release Management
+% Wei Liu <<wei.liu2@citrix.com>>
+% 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 date" and "cut-off date"). Please consider adding
+relevant events 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. The Release Manager can say "not releasing
+now" because of too many bugs, "until someone fixes these", or "no more
+patches until X, Y, and Z happen".
+
+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.
+
+2. Send an email to xen-devel, xen-users and xen-announce to announce the RC.
+
+3. Branch and / or reopen the tree for further feature submission if
+appropriate.
+
+4. Collect and track any issues reported, determine their severity, prod
+relevant developers and maintainers to fix the issues.
+
+5. When patches to fix issues are posted, determine if the patches are good to
+be included.
+
+6. 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.
+
+1. Collate a list of major changes: this should be done in collaboration
+between Release Manager, PR Personnel and key contributors. This should *not*
+be done on a public mailing list, to minimize the risk of release related
+media stories being published before the release date.
+
+2. PR Personnel will identify feature highlights, a theme for the press
+release, companies providing supporting quotes for the press release and
+media outlets we would want to reach out to and will manage the creation of
+the press release in private.
+
+3. The Community Manager will also draft blog post with the help of PR
+Personnel and Release Manager, which will be published under the name of the
+Release Manager.
+
+4. The Community Manager will create release related documentation such as
+Acknowledgements, Feature List, Man Pages and Release Notes on the wiki
+accessible via a release category. This can be done in public.
+
+5. PR Personnel will get stake-holder and Advisory Board approval for the
+press release (1-2 weeks before 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@.
+
+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. Negotiate release date options with PR personnel. Typically we needs 3-4
+days to line up press briefings with reporters under embargo. PR personnel
+will also need to consider industry events to ensure that PR is effective. PR
+releases typically done mid-week (Tuesday - Thursday).
+
+4. Select the release date.
+
+5. 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>)
+
+6. Obtain a formal go-ahead from
+
+    * the Community Manager
+    * the Release Technician
+
+    Ask them to dry-run their checklist and confirm everything is OK. If not,
+    arrange another RC and restart this checklist.
+
+7. Give PR Personnel final go-ahead, and instruct Release Technician to make
+release deliverables (tags and tarballs - will usually be in place the day
+before the release). At this point, PR collateral will be sent to reporters
+(typically 2-3 working days before the release date) and we cannot undo
+publications without questions being asked and risk of negative PR. It is
+acceptable to make a xen-devel@ announcement *before* the PR release date
+(blog, xen-announce@, press release).
+
+8. Make the announcement on various mailing list, publish the blog post.
+
+Allow for contingencies. 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, coordinate with the Security Team to adjust the
+dates according to our security policy.
+
+## Hand over of Release Manager responsibility
+
+If there is a new Release Manager for the next release, make sure the
+following things happen for the new Release Manager.
+
+1. A JIRA (xenproject.atlassian.net) is created and proper permissions granted.
+2. Access to community test infrastructure is granted.
+3. Access to mailing list moderation panel is granted.
+4. An account for blog.xenproject.org is created.
+5. An account for wiki.xenproject.org is created.
+
+# Email templates and scripts
+
+Note: if you want specific actions from committers, please make sure you CC
+committers@.
+
+## RC emails
+
+```
+Subject: Xen X.Y rcZ
+
+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
+```
+
+## Forego control of the tree
+
+```
+Subject: No Release Ack needed before RcX
+
+Committers,
+
+The tree is in good state. No release ack is needed before RcX. Please commit
+bug fixes at will.
+
+$RM
+```
+
+## Commit moratorium
+
+```
+Subject: Commit moratorium for $REASON
+
+Committers,
+
+Please don't push any new patch to staging because $REASON.
+
+Another email will be sent once the moratorium is lifted.
+
+$RM
+```
+
+## Lift commit moratorium
+
+```
+Subject: Commit moratorium is lifted for $REASON
+
+Committers,
+
+The commit moratorium is lifted, please commit patches that are already
+Release-acked.
+
+$RM
+```
+
+## Reminder of last posting date
+
+```
+Subject: Last posting date for Xen X.Y is $DATE
+
+Hi all,
+
+The last posting date for Xen X.Y is $DATE. If you want your features to be
+included for the release, please make sure they are posted for the first
+time before $DATE.
+
+$RM
+```
+
+## Reminder of cut-off date
+
+```
+Subject: Cut-off date for Xen X.Y is $DATE
+
+Hi all,
+
+The cut-off date for Xen X.Y is $DATE. If you want your features to be
+included for the release, please make sure they are committed by $DATE.
+
+$RM
+```
+
+## Release announcement
+
+```
+ Subject: [ANNOUNCEMENT] Xen X.Y is released
+
+ Dear community members,
+
+ I'm pleased to announce that Xen X.Y.0 is released.
+
+ Please find the tarball and its signature at:
+
+ https://xenproject.org/downloads/xen-archives/xen-project-xy-series/xen-project-xy0.html
+
+ You can also check out the tag in xen.git:
+
+   https://xenbits.xen.org/git-http/xen.git RELEASE-X.Y.0
+
+ Git checkout and build instructions can be found at:
+
+ https://wiki.xenproject.org/wiki/Xen_Project_X.Y_Release_Notes#Build_Requirements
+
+ Release notes can be found at:
+
+   https://wiki.xenproject.org/wiki/Xen_Project_X.Y_Release_Notes
+
+ A summary for X.Y release documents can be found at:
+
+   https://wiki.xenproject.org/wiki/Category:Xen_X.Y
+
+ Technical blog post for X.Y can be found at:
+
+  URL_TO_BLOG
+
+ Thanks everyone who contributed to this release. This release would
+ not have happened without all the awesome contributions from around
+ the globe.
+
+ Regards,
+
+ $RM (on behalf of the Xen Project Hypervisor team)
+```
+
+
+## Script to generate months update emails
+
+```
+#!/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.wilk@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-devel@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
+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 =
+
+EOF
+
+POST=`mktemp`
+cat <<EOF > $POST
+
+EOF
+
+# Preamble
+cat $PRE
+rm $PRE
+# Body
+cat $FILE | awk -f $AWK_FILE
+rm $AWK_FILE
+rm $FILE
+cat $POST
+rm $POST
+```
-- 
2.11.0


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

[PATCH 3/3] docs: hook up process/ to build system

[Wei Liu]

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 docs/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/Makefile b/docs/Makefile
index 942247202a..6743fa3744 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -17,7 +17,7 @@ MARKDOWNSRC-y := $(sort $(shell find misc -name '*.markdown' -print))
 
 TXTSRC-y := $(sort $(shell find misc -name '*.txt' -print))
 
-PANDOCSRC-y := $(sort $(shell find features/ misc/ specs/ -name '*.pandoc' -print))
+PANDOCSRC-y := $(sort $(shell find process/ features/ misc/ specs/ -name '*.pandoc' -print))
 
 # Documentation targets
 DOC_MAN1 := $(patsubst man/%.pod.1,man1/%.1,$(MAN1SRC-y)) \
-- 
2.11.0


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

Re: [PATCH 0/3] Docs: consolidate release related documents

[Ian Jackson]

Wei Liu writes ("[PATCH 0/3] Docs: consolidate release related documents"):
> Wei Liu (3):
>   docs: consolidate release related documents
>   docs: add xen-release-management.pandoc
>   docs: hook up process/ to build system

FWIW,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

However, AFAICT the mean reason this doesn't process
release-checklist.txt and branching-checklist.txt into files on the
website is that you only have it process pandocs.

But I don't think those files are ever going to want to be made into
web pages.  Whereas it is possible that we will grow other process
documents in .txt form which do, and no provision is made for them.

I wonder if it would be better to rename those to files to a different
directory.  The reason I invented misc/ was precisely to avoid people
(users and developers) tripping over them thinking they might be
useful...

Ian.

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

Re: [PATCH 0/3] Docs: consolidate release related documents

[Wei Liu]

On Mon, Jul 31, 2017 at 02:51:21PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH 0/3] Docs: consolidate release related documents"):
> > Wei Liu (3):
> >   docs: consolidate release related documents
> >   docs: add xen-release-management.pandoc
> >   docs: hook up process/ to build system
> 
> FWIW,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> However, AFAICT the mean reason this doesn't process
> release-checklist.txt and branching-checklist.txt into files on the
> website is that you only have it process pandocs.
> 

Correct, that's deliberate.

> But I don't think those files are ever going to want to be made into
> web pages.  Whereas it is possible that we will grow other process
> documents in .txt form which do, and no provision is made for them.
> 
> I wonder if it would be better to rename those to files to a different
> directory.  The reason I invented misc/ was precisely to avoid people
> (users and developers) tripping over them thinking they might be
> useful...
> 

Lars (?) said there should be a "process" directory, hence I put
everything that's relevant here.

I'm open to suggestions about directory structure. Maybe having a
technician-checklist directory under process?

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

Re: [PATCH 2/3] docs: add xen-release-management.pandoc

[Juergen Gross]

On 31/07/17 13:22, Wei Liu wrote:
> A document for the release manager.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

With two minor corrections (see below):

Reviewed-by: Juergen Gross <jgross@suse.com>

> ---
>  docs/process/xen-release-management.pandoc | 594 +++++++++++++++++++++++++++++
>  1 file changed, 594 insertions(+)
>  create mode 100644 docs/process/xen-release-management.pandoc
> 
> diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc
> new file mode 100644
> index 0000000000..afdf559429
> --- /dev/null
> +++ b/docs/process/xen-release-management.pandoc
> @@ -0,0 +1,594 @@
> +% Xen Release Management
> +% Wei Liu <<wei.liu2@citrix.com>>
> +% 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 date" and "cut-off date"). Please consider adding
> +relevant events 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. The Release Manager can say "not releasing
> +now" because of too many bugs, "until someone fixes these", or "no more
> +patches until X, Y, and Z happen".
> +
> +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.
> +
> +2. Send an email to xen-devel, xen-users and xen-announce to announce the RC.
> +
> +3. Branch and / or reopen the tree for further feature submission if
> +appropriate.
> +
> +4. Collect and track any issues reported, determine their severity, prod
> +relevant developers and maintainers to fix the issues.
> +
> +5. When patches to fix issues are posted, determine if the patches are good to
> +be included.
> +
> +6. 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.
> +
> +1. Collate a list of major changes: this should be done in collaboration
> +between Release Manager, PR Personnel and key contributors. This should *not*
> +be done on a public mailing list, to minimize the risk of release related
> +media stories being published before the release date.
> +
> +2. PR Personnel will identify feature highlights, a theme for the press
> +release, companies providing supporting quotes for the press release and
> +media outlets we would want to reach out to and will manage the creation of
> +the press release in private.
> +
> +3. The Community Manager will also draft blog post with the help of PR
> +Personnel and Release Manager, which will be published under the name of the
> +Release Manager.
> +
> +4. The Community Manager will create release related documentation such as
> +Acknowledgements, Feature List, Man Pages and Release Notes on the wiki
> +accessible via a release category. This can be done in public.
> +
> +5. PR Personnel will get stake-holder and Advisory Board approval for the
> +press release (1-2 weeks before 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@.
> +
> +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. Negotiate release date options with PR personnel. Typically we needs 3-4

either s/we/it/ or s/needs/need/

> +days to line up press briefings with reporters under embargo. PR personnel
> +will also need to consider industry events to ensure that PR is effective. PR
> +releases typically done mid-week (Tuesday - Thursday).
> +
> +4. Select the release date.
> +
> +5. 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>)
> +
> +6. Obtain a formal go-ahead from
> +
> +    * the Community Manager
> +    * the Release Technician
> +
> +    Ask them to dry-run their checklist and confirm everything is OK. If not,
> +    arrange another RC and restart this checklist.
> +
> +7. Give PR Personnel final go-ahead, and instruct Release Technician to make
> +release deliverables (tags and tarballs - will usually be in place the day
> +before the release). At this point, PR collateral will be sent to reporters
> +(typically 2-3 working days before the release date) and we cannot undo
> +publications without questions being asked and risk of negative PR. It is
> +acceptable to make a xen-devel@ announcement *before* the PR release date
> +(blog, xen-announce@, press release).
> +
> +8. Make the announcement on various mailing list, publish the blog post.
> +
> +Allow for contingencies. 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, coordinate with the Security Team to adjust the
> +dates according to our security policy.
> +
> +## Hand over of Release Manager responsibility
> +
> +If there is a new Release Manager for the next release, make sure the
> +following things happen for the new Release Manager.
> +
> +1. A JIRA (xenproject.atlassian.net) is created and proper permissions granted.
> +2. Access to community test infrastructure is granted.
> +3. Access to mailing list moderation panel is granted.
> +4. An account for blog.xenproject.org is created.
> +5. An account for wiki.xenproject.org is created.
> +
> +# Email templates and scripts
> +
> +Note: if you want specific actions from committers, please make sure you CC
> +committers@.
> +
> +## RC emails
> +
> +```
> +Subject: Xen X.Y rcZ
> +
> +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
> +```
> +
> +## Forego control of the tree
> +
> +```
> +Subject: No Release Ack needed before RcX
> +
> +Committers,
> +
> +The tree is in good state. No release ack is needed before RcX. Please commit
> +bug fixes at will.
> +
> +$RM
> +```
> +
> +## Commit moratorium
> +
> +```
> +Subject: Commit moratorium for $REASON
> +
> +Committers,
> +
> +Please don't push any new patch to staging because $REASON.
> +
> +Another email will be sent once the moratorium is lifted.
> +
> +$RM
> +```
> +
> +## Lift commit moratorium
> +
> +```
> +Subject: Commit moratorium is lifted for $REASON
> +
> +Committers,
> +
> +The commit moratorium is lifted, please commit patches that are already
> +Release-acked.
> +
> +$RM
> +```
> +
> +## Reminder of last posting date
> +
> +```
> +Subject: Last posting date for Xen X.Y is $DATE
> +
> +Hi all,
> +
> +The last posting date for Xen X.Y is $DATE. If you want your features to be
> +included for the release, please make sure they are posted for the first
> +time before $DATE.
> +
> +$RM
> +```
> +
> +## Reminder of cut-off date
> +
> +```
> +Subject: Cut-off date for Xen X.Y is $DATE
> +
> +Hi all,
> +
> +The cut-off date for Xen X.Y is $DATE. If you want your features to be
> +included for the release, please make sure they are committed by $DATE.
> +
> +$RM
> +```
> +
> +## Release announcement
> +
> +```
> + Subject: [ANNOUNCEMENT] Xen X.Y is released
> +
> + Dear community members,
> +
> + I'm pleased to announce that Xen X.Y.0 is released.
> +
> + Please find the tarball and its signature at:
> +
> + https://xenproject.org/downloads/xen-archives/xen-project-xy-series/xen-project-xy0.html
> +
> + You can also check out the tag in xen.git:
> +
> +   https://xenbits.xen.org/git-http/xen.git RELEASE-X.Y.0
> +
> + Git checkout and build instructions can be found at:
> +
> + https://wiki.xenproject.org/wiki/Xen_Project_X.Y_Release_Notes#Build_Requirements
> +
> + Release notes can be found at:
> +
> +   https://wiki.xenproject.org/wiki/Xen_Project_X.Y_Release_Notes
> +
> + A summary for X.Y release documents can be found at:
> +
> +   https://wiki.xenproject.org/wiki/Category:Xen_X.Y
> +
> + Technical blog post for X.Y can be found at:
> +
> +  URL_TO_BLOG
> +
> + Thanks everyone who contributed to this release. This release would
> + not have happened without all the awesome contributions from around
> + the globe.
> +
> + Regards,
> +
> + $RM (on behalf of the Xen Project Hypervisor team)
> +```
> +
> +
> +## Script to generate months update emails
> +
> +```
> +#!/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.wilk@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-devel@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

s/woulk/would/

> +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 =
> +
> +EOF
> +
> +POST=`mktemp`
> +cat <<EOF > $POST
> +
> +EOF
> +
> +# Preamble
> +cat $PRE
> +rm $PRE
> +# Body
> +cat $FILE | awk -f $AWK_FILE
> +rm $AWK_FILE
> +rm $FILE
> +cat $POST
> +rm $POST
> +```
> 

Juergen

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

Re: [PATCH 2/3] docs: add xen-release-management.pandoc

[Julien Grall]

Hi Wei,

On 31/07/17 12:22, Wei Liu wrote:
> A document for the release manager.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: Julien Grall <julien.grall@arm.com>

Cheers,

> ---
>  docs/process/xen-release-management.pandoc | 594 +++++++++++++++++++++++++++++
>  1 file changed, 594 insertions(+)
>  create mode 100644 docs/process/xen-release-management.pandoc
>
> diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc
> new file mode 100644
> index 0000000000..afdf559429
> --- /dev/null
> +++ b/docs/process/xen-release-management.pandoc
> @@ -0,0 +1,594 @@
> +% Xen Release Management
> +% Wei Liu <<wei.liu2@citrix.com>>
> +% 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 date" and "cut-off date"). Please consider adding
> +relevant events 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. The Release Manager can say "not releasing
> +now" because of too many bugs, "until someone fixes these", or "no more
> +patches until X, Y, and Z happen".
> +
> +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.
> +
> +2. Send an email to xen-devel, xen-users and xen-announce to announce the RC.
> +
> +3. Branch and / or reopen the tree for further feature submission if
> +appropriate.
> +
> +4. Collect and track any issues reported, determine their severity, prod
> +relevant developers and maintainers to fix the issues.
> +
> +5. When patches to fix issues are posted, determine if the patches are good to
> +be included.
> +
> +6. 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.
> +
> +1. Collate a list of major changes: this should be done in collaboration
> +between Release Manager, PR Personnel and key contributors. This should *not*
> +be done on a public mailing list, to minimize the risk of release related
> +media stories being published before the release date.
> +
> +2. PR Personnel will identify feature highlights, a theme for the press
> +release, companies providing supporting quotes for the press release and
> +media outlets we would want to reach out to and will manage the creation of
> +the press release in private.
> +
> +3. The Community Manager will also draft blog post with the help of PR
> +Personnel and Release Manager, which will be published under the name of the
> +Release Manager.
> +
> +4. The Community Manager will create release related documentation such as
> +Acknowledgements, Feature List, Man Pages and Release Notes on the wiki
> +accessible via a release category. This can be done in public.
> +
> +5. PR Personnel will get stake-holder and Advisory Board approval for the
> +press release (1-2 weeks before 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@.
> +
> +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. Negotiate release date options with PR personnel. Typically we needs 3-4
> +days to line up press briefings with reporters under embargo. PR personnel
> +will also need to consider industry events to ensure that PR is effective. PR
> +releases typically done mid-week (Tuesday - Thursday).
> +
> +4. Select the release date.
> +
> +5. 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>)
> +
> +6. Obtain a formal go-ahead from
> +
> +    * the Community Manager
> +    * the Release Technician
> +
> +    Ask them to dry-run their checklist and confirm everything is OK. If not,
> +    arrange another RC and restart this checklist.
> +
> +7. Give PR Personnel final go-ahead, and instruct Release Technician to make
> +release deliverables (tags and tarballs - will usually be in place the day
> +before the release). At this point, PR collateral will be sent to reporters
> +(typically 2-3 working days before the release date) and we cannot undo
> +publications without questions being asked and risk of negative PR. It is
> +acceptable to make a xen-devel@ announcement *before* the PR release date
> +(blog, xen-announce@, press release).
> +
> +8. Make the announcement on various mailing list, publish the blog post.
> +
> +Allow for contingencies. 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, coordinate with the Security Team to adjust the
> +dates according to our security policy.
> +
> +## Hand over of Release Manager responsibility
> +
> +If there is a new Release Manager for the next release, make sure the
> +following things happen for the new Release Manager.
> +
> +1. A JIRA (xenproject.atlassian.net) is created and proper permissions granted.
> +2. Access to community test infrastructure is granted.
> +3. Access to mailing list moderation panel is granted.
> +4. An account for blog.xenproject.org is created.
> +5. An account for wiki.xenproject.org is created.
> +
> +# Email templates and scripts
> +
> +Note: if you want specific actions from committers, please make sure you CC
> +committers@.
> +
> +## RC emails
> +
> +```
> +Subject: Xen X.Y rcZ
> +
> +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
> +```
> +
> +## Forego control of the tree
> +
> +```
> +Subject: No Release Ack needed before RcX
> +
> +Committers,
> +
> +The tree is in good state. No release ack is needed before RcX. Please commit
> +bug fixes at will.
> +
> +$RM
> +```
> +
> +## Commit moratorium
> +
> +```
> +Subject: Commit moratorium for $REASON
> +
> +Committers,
> +
> +Please don't push any new patch to staging because $REASON.
> +
> +Another email will be sent once the moratorium is lifted.
> +
> +$RM
> +```
> +
> +## Lift commit moratorium
> +
> +```
> +Subject: Commit moratorium is lifted for $REASON
> +
> +Committers,
> +
> +The commit moratorium is lifted, please commit patches that are already
> +Release-acked.
> +
> +$RM
> +```
> +
> +## Reminder of last posting date
> +
> +```
> +Subject: Last posting date for Xen X.Y is $DATE
> +
> +Hi all,
> +
> +The last posting date for Xen X.Y is $DATE. If you want your features to be
> +included for the release, please make sure they are posted for the first
> +time before $DATE.
> +
> +$RM
> +```
> +
> +## Reminder of cut-off date
> +
> +```
> +Subject: Cut-off date for Xen X.Y is $DATE
> +
> +Hi all,
> +
> +The cut-off date for Xen X.Y is $DATE. If you want your features to be
> +included for the release, please make sure they are committed by $DATE.
> +
> +$RM
> +```
> +
> +## Release announcement
> +
> +```
> + Subject: [ANNOUNCEMENT] Xen X.Y is released
> +
> + Dear community members,
> +
> + I'm pleased to announce that Xen X.Y.0 is released.
> +
> + Please find the tarball and its signature at:
> +
> + https://xenproject.org/downloads/xen-archives/xen-project-xy-series/xen-project-xy0.html
> +
> + You can also check out the tag in xen.git:
> +
> +   https://xenbits.xen.org/git-http/xen.git RELEASE-X.Y.0
> +
> + Git checkout and build instructions can be found at:
> +
> + https://wiki.xenproject.org/wiki/Xen_Project_X.Y_Release_Notes#Build_Requirements
> +
> + Release notes can be found at:
> +
> +   https://wiki.xenproject.org/wiki/Xen_Project_X.Y_Release_Notes
> +
> + A summary for X.Y release documents can be found at:
> +
> +   https://wiki.xenproject.org/wiki/Category:Xen_X.Y
> +
> + Technical blog post for X.Y can be found at:
> +
> +  URL_TO_BLOG
> +
> + Thanks everyone who contributed to this release. This release would
> + not have happened without all the awesome contributions from around
> + the globe.
> +
> + Regards,
> +
> + $RM (on behalf of the Xen Project Hypervisor team)
> +```
> +
> +
> +## Script to generate months update emails
> +
> +```
> +#!/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.wilk@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-devel@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
> +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 =
> +
> +EOF
> +
> +POST=`mktemp`
> +cat <<EOF > $POST
> +
> +EOF
> +
> +# Preamble
> +cat $PRE
> +rm $PRE
> +# Body
> +cat $FILE | awk -f $AWK_FILE
> +rm $AWK_FILE
> +rm $FILE
> +cat $POST
> +rm $POST
> +```
>

-- 
Julien Grall

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

Re: [PATCH 2/3] docs: add xen-release-management.pandoc

[Lars Kurth]

Wei
    
On 31/07/17 12:22, Wei Liu wrote:
    > A document for the release manager.
    >
    > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    
    Reviewed-by: Lars Kurth <lars.kurth@citrix.com>

  Regards
  Lars


On 08/08/2017, 12:03, "Julien Grall" <julien.grall@arm.com> wrote:

    Hi Wei,
    
    On 31/07/17 12:22, Wei Liu wrote:
    > A document for the release manager.
    >
    > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    
    Reviewed-by: Julien Grall <julien.grall@arm.com>
    
    Cheers,
    
    > ---
    >  docs/process/xen-release-management.pandoc | 594 +++++++++++++++++++++++++++++
    >  1 file changed, 594 insertions(+)
    >  create mode 100644 docs/process/xen-release-management.pandoc
    >
    > diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc
    > new file mode 100644
    > index 0000000000..afdf559429
    > --- /dev/null
    > +++ b/docs/process/xen-release-management.pandoc
    > @@ -0,0 +1,594 @@
    > +% Xen Release Management
    > +% Wei Liu <<wei.liu2@citrix.com>>
    > +% 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 date" and "cut-off date"). Please consider adding
    > +relevant events 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. The Release Manager can say "not releasing
    > +now" because of too many bugs, "until someone fixes these", or "no more
    > +patches until X, Y, and Z happen".
    > +
    > +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.
    > +
    > +2. Send an email to xen-devel, xen-users and xen-announce to announce the RC.
    > +
    > +3. Branch and / or reopen the tree for further feature submission if
    > +appropriate.
    > +
    > +4. Collect and track any issues reported, determine their severity, prod
    > +relevant developers and maintainers to fix the issues.
    > +
    > +5. When patches to fix issues are posted, determine if the patches are good to
    > +be included.
    > +
    > +6. 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.
    > +
    > +1. Collate a list of major changes: this should be done in collaboration
    > +between Release Manager, PR Personnel and key contributors. This should *not*
    > +be done on a public mailing list, to minimize the risk of release related
    > +media stories being published before the release date.
    > +
    > +2. PR Personnel will identify feature highlights, a theme for the press
    > +release, companies providing supporting quotes for the press release and
    > +media outlets we would want to reach out to and will manage the creation of
    > +the press release in private.
    > +
    > +3. The Community Manager will also draft blog post with the help of PR
    > +Personnel and Release Manager, which will be published under the name of the
    > +Release Manager.
    > +
    > +4. The Community Manager will create release related documentation such as
    > +Acknowledgements, Feature List, Man Pages and Release Notes on the wiki
    > +accessible via a release category. This can be done in public.
    > +
    > +5. PR Personnel will get stake-holder and Advisory Board approval for the
    > +press release (1-2 weeks before 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@.
    > +
    > +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. Negotiate release date options with PR personnel. Typically we needs 3-4
    > +days to line up press briefings with reporters under embargo. PR personnel
    > +will also need to consider industry events to ensure that PR is effective. PR
    > +releases typically done mid-week (Tuesday - Thursday).
    > +
    > +4. Select the release date.
    > +
    > +5. 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>)
    > +
    > +6. Obtain a formal go-ahead from
    > +
    > +    * the Community Manager
    > +    * the Release Technician
    > +
    > +    Ask them to dry-run their checklist and confirm everything is OK. If not,
    > +    arrange another RC and restart this checklist.
    > +
    > +7. Give PR Personnel final go-ahead, and instruct Release Technician to make
    > +release deliverables (tags and tarballs - will usually be in place the day
    > +before the release). At this point, PR collateral will be sent to reporters
    > +(typically 2-3 working days before the release date) and we cannot undo
    > +publications without questions being asked and risk of negative PR. It is
    > +acceptable to make a xen-devel@ announcement *before* the PR release date
    > +(blog, xen-announce@, press release).
    > +
    > +8. Make the announcement on various mailing list, publish the blog post.
    > +
    > +Allow for contingencies. 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, coordinate with the Security Team to adjust the
    > +dates according to our security policy.
    > +
    > +## Hand over of Release Manager responsibility
    > +
    > +If there is a new Release Manager for the next release, make sure the
    > +following things happen for the new Release Manager.
    > +
    > +1. A JIRA (xenproject.atlassian.net) is created and proper permissions granted.
    > +2. Access to community test infrastructure is granted.
    > +3. Access to mailing list moderation panel is granted.
    > +4. An account for blog.xenproject.org is created.
    > +5. An account for wiki.xenproject.org is created.
    > +
    > +# Email templates and scripts
    > +
    > +Note: if you want specific actions from committers, please make sure you CC
    > +committers@.
    > +
    > +## RC emails
    > +
    > +```
    > +Subject: Xen X.Y rcZ
    > +
    > +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
    > +```
    > +
    > +## Forego control of the tree
    > +
    > +```
    > +Subject: No Release Ack needed before RcX
    > +
    > +Committers,
    > +
    > +The tree is in good state. No release ack is needed before RcX. Please commit
    > +bug fixes at will.
    > +
    > +$RM
    > +```
    > +
    > +## Commit moratorium
    > +
    > +```
    > +Subject: Commit moratorium for $REASON
    > +
    > +Committers,
    > +
    > +Please don't push any new patch to staging because $REASON.
    > +
    > +Another email will be sent once the moratorium is lifted.
    > +
    > +$RM
    > +```
    > +
    > +## Lift commit moratorium
    > +
    > +```
    > +Subject: Commit moratorium is lifted for $REASON
    > +
    > +Committers,
    > +
    > +The commit moratorium is lifted, please commit patches that are already
    > +Release-acked.
    > +
    > +$RM
    > +```
    > +
    > +## Reminder of last posting date
    > +
    > +```
    > +Subject: Last posting date for Xen X.Y is $DATE
    > +
    > +Hi all,
    > +
    > +The last posting date for Xen X.Y is $DATE. If you want your features to be
    > +included for the release, please make sure they are posted for the first
    > +time before $DATE.
    > +
    > +$RM
    > +```
    > +
    > +## Reminder of cut-off date
    > +
    > +```
    > +Subject: Cut-off date for Xen X.Y is $DATE
    > +
    > +Hi all,
    > +
    > +The cut-off date for Xen X.Y is $DATE. If you want your features to be
    > +included for the release, please make sure they are committed by $DATE.
    > +
    > +$RM
    > +```
    > +
    > +## Release announcement
    > +
    > +```
    > + Subject: [ANNOUNCEMENT] Xen X.Y is released
    > +
    > + Dear community members,
    > +
    > + I'm pleased to announce that Xen X.Y.0 is released.
    > +
    > + Please find the tarball and its signature at:
    > +
    > + https://xenproject.org/downloads/xen-archives/xen-project-xy-series/xen-project-xy0.html
    > +
    > + You can also check out the tag in xen.git:
    > +
    > +   https://xenbits.xen.org/git-http/xen.git RELEASE-X.Y.0
    > +
    > + Git checkout and build instructions can be found at:
    > +
    > + https://wiki.xenproject.org/wiki/Xen_Project_X.Y_Release_Notes#Build_Requirements
    > +
    > + Release notes can be found at:
    > +
    > +   https://wiki.xenproject.org/wiki/Xen_Project_X.Y_Release_Notes
    > +
    > + A summary for X.Y release documents can be found at:
    > +
    > +   https://wiki.xenproject.org/wiki/Category:Xen_X.Y
    > +
    > + Technical blog post for X.Y can be found at:
    > +
    > +  URL_TO_BLOG
    > +
    > + Thanks everyone who contributed to this release. This release would
    > + not have happened without all the awesome contributions from around
    > + the globe.
    > +
    > + Regards,
    > +
    > + $RM (on behalf of the Xen Project Hypervisor team)
    > +```
    > +
    > +
    > +## Script to generate months update emails
    > +
    > +```
    > +#!/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.wilk@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-devel@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
    > +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 =
    > +
    > +EOF
    > +
    > +POST=`mktemp`
    > +cat <<EOF > $POST
    > +
    > +EOF
    > +
    > +# Preamble
    > +cat $PRE
    > +rm $PRE
    > +# Body
    > +cat $FILE | awk -f $AWK_FILE
    > +rm $AWK_FILE
    > +rm $FILE
    > +cat $POST
    > +rm $POST
    > +```
    >
    
    -- 
    Julien Grall
    

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