On Mon, Jul 17, 2017 at 06:58:27PM +0200, Juergen Gross wrote: > On 17/07/17 17:09, Wei Liu wrote: > > It is agreed during the summit we should write down such document. Here > > is my attempt of doing so. > > > > We should probably commit something like this into xen.git so that it > > gets updated regularly. > > > > Comments are welcome. > > > > ----- > > > > % Xen Release Management > > % Wei Liu <<wei.l...@citrix.com>> > > % Revision 1 > > > > # Motivation > > > > Over the years we have had different people from different company signning > > signing >
Fixed. And I also realised I shouldn't have written "company" because I don't want to imply one has to be employed by a company to become RM. > > 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. > > > > 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. > > > > # 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 doens'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 corrdinating with external reporters to publish Xen > > coordinating > Fixed. > > 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. Please consider adding a recurring event 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. > > > > 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. > > > > 1. Send an email to xen-devel, xen-users and xen-announce to announce the > > RC. > > > > 1. Branch and / or reopen the tree for further feature submission if > > appropriate. > > > > 1. Collect and track any issues reported, determine their severity, prod > > relevant developers and maintainers to fix the issues. > > > > 1. When patches to fix issues are posted, determine if the patches are good > > to be included. > > > > 1. Go back to 1. > > To which 1.? There are plenty to choose from. :-D LOL. The first "1.". This is a markdown feature I abuse so that I don't have to remember writing the correct numbers. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel