Re: [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc

2017-08-08 Thread Lars Kurth
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. 

Re: [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc

2017-08-08 Thread Julien Grall

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 

Re: [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc

2017-08-02 Thread Juergen Gross
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