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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Jul 24, 2017 at 11:50:37AM +0100, Lars Kurth wrote:
> Hi all,
> 
> I went over this with a few of the actions from 
> https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#01645
>  
> <https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#01645>
> 
> Lars/Wei/Julien 
> A1 ACTION to write "standard e-mail templates for common stuff", rather than 
> re-doing these every single time
> Ian release manager file 
> 
> A2 ACTION : Clean up release technician checklist after we have the how to be
> * Add hand-over of tasks for Release Manager responsibility to the "how to be 
> release manager file"
> 
> A3 ACTION: Additional stuff to add to the templates/RM guide
> A3.1: Add clear reminders in particular at the beginning of a release into 
> e-mail templates: such as put dates X,Y, Z in your calendar add to checklist 
> and templates
> A3.2: Communicate better when tree is open again
> A3.3: Release manager can say "not releasing now" because of too many bugs, 
> "until someone fixes these". "no more patches until XYZ"

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

> 
> > 
> > 1. Go back to 1.
> > 
> > It is normally OK in the early RCs that you hand back xen-unstable branch to
> > committers so that they can commit bug fixes at will. As we approach late
> > RCs, the standard for accepting a patch will get higher and higher. Please
> > communicate clearly when committers can commit at will and when formal
> > Release Ack is needed.
> > 
> > At the same time, work with the Community Manager, PR Personnel and
> > Contributors to gather a list of features for the release. Discuss the
> > support status of new features with stakeholders. Help prepare the press
> > release, write a blog post for the release.
> 

> Does it make sense to move this into a separate section, or have a
> separate section which list the key steps? If so, I am happy to pull
> this together. Primarily I tend to drive the PR angle with Zibby and
> would be happy to create a checklist. The Release Manager's role here
> is one of providing input, but can (if desired) be more high profile
> (e.g. quotes in releases). 
> 

Yes, I think that would be good.

> > 
> > When you think all pending issues are fixed and Xen is ready to be released
> > from the last RC:
> > 
> > 1. Send out commit moratorium emails to committers@.
> > 
> > 1. Check all the trees (mini-os, qemu-trad, qemu-xen, seabios, ovmf etc).
> > They have the correct commits and all security patches applied. There will 
> > be
> > tools provided.
> > 
> > 1. Ask the Community Manager and Release Technician to double-check all
> > security patches have been applied. If not, apply them, arrange another RC
> > and restart this checklist.
> 
> I think double checking is good. If 
> http://xenbits.xenproject.org/gitweb/?p=people/larsk/xen-release-scripts.git 
> <http://xenbits.xenproject.org/gitweb/?p=people/larsk/xen-release-scripts.git>
>  are deemed to be fit for purpose, we should probably refer to these
> 
> > 1. Ask the Release Technician to tag the trees and make the tarball. Ask the
> > Community Manager to update relevant web assets.
> 
> Add:
> 

> 1. Check with relevant stake-holders (typically community manager)
> whether wiki documentation and PR is in good shape (for an example see
> https://wiki.xenproject.org/wiki/Category:Xen_4.9
> <https://wiki.xenproject.org/wiki/Category:Xen_4.9>)

> 
> > 
> > 1. Give the PR Personnel signal to proceed. Cooridinate with him / her on 
> > the
> > public annoucement.
> 
> Typically we will need a bit of lead-time here to ensure that everything is 
> in place

How much time would be considered typical?

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

> 
> 
> > 1. Make the announcement on various mailing list, publish the blog post.
> > 
> > Allow for contigencies. It is not uncommon that some last minute (security 
> > or
> > not) bugs are discovered. To provide a fix takes time, the test of the fix
> > will also take time. Allow for at least 1 week from getting a fix to getting
> > a push. For security bugs, corrdinate with the Security Team to adjust the
> > dates according to our security policy.
> > 
> > 
> 
> There should probably be a section along the lines of (for A2)
> 
> ## Hand over of Release Manager Responsibility
> 
> Probably this is an area where Wei, George, Konrad and Julien have experience.
> 
> This should include a list of systems a Release Manager should be signed up 
> to, such as blog account, xen-announce, ...
> 

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

I think mentioning various creation is good.

> > # Email templates
> > 
> > ## RC emails
> > 
> >> Hi all,
> >> 
> >> Xen X.Y rcZ is tagged. You can check that out from xen.git:
> >> 
> >> git://xenbits.xen.org/xen.git X.Y.0-rcZ
> >> 
> >> For your convenience there is also a tarball at:
> >> https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz
> >> 
> >> And the signature is at:
> >> https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz.sig
> >> 
> >> Please send bug reports and test reports to xen-devel@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
> 
> We should probably have mail templates for the specific stages of the
> process, which can then include reminders to add calendar entries (see
> A3.1)

OK.

> 

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