Re: [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc
Wei On 31/07/17 12:22, Wei Liu wrote: > A document for the release manager. > > Signed-off-by: Wei Liu Reviewed-by: Lars Kurth Regards Lars On 08/08/2017, 12:03, "Julien Grall" wrote: Hi Wei, On 31/07/17 12:22, Wei Liu wrote: > A document for the release manager. > > Signed-off-by: Wei Liu Reviewed-by: Julien Grall 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 00..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
Re: [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc
Hi Wei, On 31/07/17 12:22, Wei Liu wrote: A document for the release manager. Signed-off-by: Wei Liu Reviewed-by: Julien Grall 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 00..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 +relea
Re: [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc
On 31/07/17 13:22, Wei Liu wrote: > A document for the release manager. > > Signed-off-by: Wei Liu With two minor corrections (see below): Reviewed-by: Juergen Gross > --- > 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 00..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 xenproje
[Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc
A document for the release manager. Signed-off-by: Wei Liu --- 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 00..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
