From patchwork Mon Jul 31 11:22:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Liu X-Patchwork-Id: 9871611 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1C0D2602F0 for ; Mon, 31 Jul 2017 11:25:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0E8BA28403 for ; Mon, 31 Jul 2017 11:25:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0352B2858F; Mon, 31 Jul 2017 11:25:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id A5FE828403 for ; Mon, 31 Jul 2017 11:25:28 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dc8mn-0006L8-KG; Mon, 31 Jul 2017 11:22:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dc8mm-0006KH-9g for xen-devel@lists.xenproject.org; Mon, 31 Jul 2017 11:22:56 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 43/F0-02176-F031F795; Mon, 31 Jul 2017 11:22:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRWlGSWpSXmKPExsXitHSDvS6fcH2 kwc33Whbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8aHTYIFlyYwVmxck9LAeLysi5GDQ0LAX+Ln Bf8uRk4ONgFliZ+dvWwgtoiAnkTTgeeMXYxcHMwCWxklll2eDZYQFrCRePH4JjtIL4uAqkTTf VaQMK+AhcTUB3OYQWwJAXmJXW0XweKcApYSjb9bWUBsIaCa/49uMULYChId048xQfQKSpyc+Q SshllAQuLgixfMExh5ZyFJzUKSWsDItIpRozi1qCy1SNfQQi+pKDM9oyQ3MTNH19DAVC83tbg 4MT01JzGpWC85P3cTIzBwGIBgB2PTds9DjJIcTEqivA8Y6yOF+JLyUyozEosz4otKc1KLDzHK cHAoSfAyCAHlBItS01Mr0jJzgCEMk5bg4FES4VUASfMWFyTmFmemQ6ROMVpybFi9/gsTx5zfO 4Dkqwn/vzEJseTl56VKifMeEQRqEABpyCjNgxsHi7NLjLJSwryMQAcK8RSkFuVmlqDKv2IU52 BUAqoAWcuTmVcCt/UV0EFMQAdJltaCHFSSiJCSamBc8DfBeennUNs7AR98+88v2/f9eEzEvGm +O3UyL+zw2R6zIHCLG7+wxVRV1fOGJ9R2lfH7R0h2sX+Y5P/Ze2qdTNLkCCnn8PMxaZeM9KRO P7v97auMikye0R+JShmdXf+Fo7gXXL0ufiZMQ/PEyl06KZWrXXMeyh8z88p4caDk9bn1wrbvH 7xXYinOSDTUYi4qTgQA3gG+q64CAAA= X-Env-Sender: prvs=3784ef4a8=wei.liu2@citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1501500171!89278238!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.4.25; banners=-,-,- X-VirusChecked: Checked Received: (qmail 60249 invoked from network); 31 Jul 2017 11:22:54 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 31 Jul 2017 11:22:54 -0000 X-IronPort-AV: E=Sophos;i="5.40,442,1496102400"; d="scan'208";a="442012851" From: Wei Liu To: Xen-devel Date: Mon, 31 Jul 2017 12:22:47 +0100 Message-ID: <20170731112248.20670-3-wei.liu2@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170731112248.20670-1-wei.liu2@citrix.com> References: <20170731112248.20670-1-wei.liu2@citrix.com> MIME-Version: 1.0 Cc: Juergen Gross , Lars Kurth , Julien Grall , Committers , Wei Liu Subject: [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP A document for the release manager. Signed-off-by: Wei Liu Reviewed-by: Juergen Gross Reviewed-by: Julien Grall --- 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 <> +% 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 +) + +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 < $POST + +EOF + +# Preamble +cat $PRE +rm $PRE +# Body +cat $FILE | awk -f $AWK_FILE +rm $AWK_FILE +rm $FILE +cat $POST +rm $POST +```