|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc
A document for the release manager. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> --- 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@xxxxxxxxxx>> +% 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@xxxxxxxxxxxxxxxxxxxx. +When sending bug reports, please CC relevant maintainers and me +(abc@xxxxxxx). + +As a reminder, there will be another Xen Test Day. + +See instructions on: URL_TO_TEST_INSTRUCTIONS +``` + +## 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@xxxxxxxxxx +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@xxxxxxxxxxxxxxxxxxxx" +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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |