[PATCH v2] doc: Add maintainer process

[PATCH v2] doc: Add maintainer process

[Alexander Smirnov]

This patch adds basic maintainer process description, that has been
used so far since the project start.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 doc/maintainer.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 doc/maintainer.md

diff --git a/doc/maintainer.md b/doc/maintainer.md
new file mode 100644
index 0000000..2b9a8c7
--- /dev/null
+++ b/doc/maintainer.md
@@ -0,0 +1,52 @@
+# Introduction
+
+Isar maintainer is the person who keeps the project development in
+compliance with the contributing process definition. The purpose of
+this document is to describe the maintainer process in the Isar
+project.
+
+# Responsibilities
+
+## Feedback on Contributions
+
+The Isar maintainer should review each contribution that has been sent
+to the mailing list and provide feedback. The feedback could be on of
+the following categories:
+
+ - Contribution accepted: If no quality and design issues were found
+   by the maintainer and the other mailing list members.
+
+ - Change request: If some small quality or design issues were found,
+   the maintainer or the other mailing list memeber requests a new
+   version with resolved issues.
+
+ - Contribution rejected: If there are major design issues or general
+   benefit from the contribution is ambiguous.
+
+During the review, the maintainer may ask additional questions to
+clarify the details. Any other mailing list member could assist the
+maintainer in the review process.
+
+## Repository Branches
+
+There are two official branches in Isar, intended to increase project
+quality:
+
+ - next: The accepted contributions from the mailing list are merged
+   to this branch. Basic CI checks should be run after each merge.
+   This branch could be forced.
+
+ - master: Is the official stable branch. The only way patches go in
+   here is coming from 'next', where they have passed all required
+   tests and undergone the review process. On this branch force-pushing
+   will never be used.
+
+The next branch is intended to be merged into master monthly. The
+maintainer could perform a merge to master before the ordinary window
+if the next branch contains urgent patch series (bug fixes or critical
+features).
+
+## Issues at GitHub
+
+For each issue that has been found in master and next branches the
+maintainer should create a GitHub issue.
-- 
2.1.4

Re: [PATCH v2] doc: Add maintainer process

[Jan Kiszka]

On 2017-09-13 18:28, Alexander Smirnov wrote:
> This patch adds basic maintainer process description, that has been
> used so far since the project start.
> 
> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> ---
>  doc/maintainer.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>  create mode 100644 doc/maintainer.md
> 
> diff --git a/doc/maintainer.md b/doc/maintainer.md
> new file mode 100644
> index 0000000..2b9a8c7
> --- /dev/null
> +++ b/doc/maintainer.md
> @@ -0,0 +1,52 @@
> +# Introduction
> +
> +Isar maintainer is the person who keeps the project development in
> +compliance with the contributing process definition. The purpose of
> +this document is to describe the maintainer process in the Isar
> +project.
> +
> +# Responsibilities
> +
> +## Feedback on Contributions
> +
> +The Isar maintainer should review each contribution that has been sent
> +to the mailing list and provide feedback. The feedback could be on of

"can be" - or "shall be"? Recommendation or clear definition?

Also: s/on/one/

> +the following categories:
> +
> + - Contribution accepted: If no quality and design issues were found
> +   by the maintainer and the other mailing list members.
> +
> + - Change request: If some small quality or design issues were found,
> +   the maintainer or the other mailing list memeber requests a new
> +   version with resolved issues.
> +
> + - Contribution rejected: If there are major design issues or general
> +   benefit from the contribution is ambiguous.
> +
> +During the review, the maintainer may ask additional questions to
> +clarify the details. Any other mailing list member could assist the
> +maintainer in the review process.
> +
> +## Repository Branches
> +
> +There are two official branches in Isar, intended to increase project
> +quality:
> +
> + - next: The accepted contributions from the mailing list are merged
> +   to this branch. Basic CI checks should be run after each merge.
> +   This branch could be forced.

I think you mean "can be rebased" or "change non-linearly".

> +
> + - master: Is the official stable branch. The only way patches go in
> +   here is coming from 'next', where they have passed all required
> +   tests and undergone the review process. On this branch force-pushing
> +   will never be used.
> +
> +The next branch is intended to be merged into master monthly. The
> +maintainer could perform a merge to master before the ordinary window

"may perform"

> +if the next branch contains urgent patch series (bug fixes or critical
> +features).
> +
> +## Issues at GitHub
> +
> +For each issue that has been found in master and next branches the
> +maintainer should create a GitHub issue.
> 

That does not define what an "issue" is (e.g. granularity).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2] doc: Add maintainer process

[Henning Schild]

Am Wed, 13 Sep 2017 19:28:19 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> This patch adds basic maintainer process description, that has been
> used so far since the project start.
> 
> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> ---
>  doc/maintainer.md | 52
> ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed,
> 52 insertions(+) create mode 100644 doc/maintainer.md
> 
> diff --git a/doc/maintainer.md b/doc/maintainer.md
> new file mode 100644
> index 0000000..2b9a8c7
> --- /dev/null
> +++ b/doc/maintainer.md
> @@ -0,0 +1,52 @@
> +# Introduction
> +
> +Isar maintainer is the person who keeps the project development in
> +compliance with the contributing process definition. The purpose of
> +this document is to describe the maintainer process in the Isar
> +project.
> +
> +# Responsibilities
> +
> +## Feedback on Contributions
> +
> +The Isar maintainer should review each contribution that has been
> sent +to the mailing list and provide feedback. The feedback could be
> on of +the following categories:

The feedback could be on the following categories

The rest looks good,
Henning

> +
> + - Contribution accepted: If no quality and design issues were found
> +   by the maintainer and the other mailing list members.
> +
> + - Change request: If some small quality or design issues were found,
> +   the maintainer or the other mailing list memeber requests a new
> +   version with resolved issues.
> +
> + - Contribution rejected: If there are major design issues or general
> +   benefit from the contribution is ambiguous.
> +
> +During the review, the maintainer may ask additional questions to
> +clarify the details. Any other mailing list member could assist the
> +maintainer in the review process.
> +
> +## Repository Branches
> +
> +There are two official branches in Isar, intended to increase project
> +quality:
> +
> + - next: The accepted contributions from the mailing list are merged
> +   to this branch. Basic CI checks should be run after each merge.
> +   This branch could be forced.
> +
> + - master: Is the official stable branch. The only way patches go in
> +   here is coming from 'next', where they have passed all required
> +   tests and undergone the review process. On this branch
> force-pushing
> +   will never be used.
> +
> +The next branch is intended to be merged into master monthly. The
> +maintainer could perform a merge to master before the ordinary window
> +if the next branch contains urgent patch series (bug fixes or
> critical +features).
> +
> +## Issues at GitHub
> +
> +For each issue that has been found in master and next branches the
> +maintainer should create a GitHub issue.