[PATCH] Maintainer process

[PATCH] Maintainer process

[Alexander Smirnov]

Hello all,

this patch describes the basic maintainer process that has been used
so far in Isar since the project start. This process is being tunned,
so any proposals are welcome.

With best regards,
Alex

8<--

Alexander Smirnov (1):
  doc: Add maintainer process

 doc/maintainer.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 doc/maintainer.md

-- 
2.9.4

[PATCH] 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 | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 doc/maintainer.md

diff --git a/doc/maintainer.md b/doc/maintainer.md
new file mode 100644
index 0000000..ddaf39b
--- /dev/null
+++ b/doc/maintainer.md
@@ -0,0 +1,47 @@
+# Introduction
+
+Isar maintainer is the person who keeps project development in compliance
+with contributing process definition. The purpose of this document is to
+describe the maintainer process in Isar project.
+
+# Responsibilities
+
+## Feedback on Contributions
+
+Isar maintainer should review each contribution that has been sent to
+mailing list and provide the feedback. Feedback could be on of the
+following categories:
+
+ - Contribution accepted: If no quality and design issues were found.
+
+ - Change request: If some small quality or design issues were found, the
+   maintainer requests next 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.
+
+## Repository Branches
+
+There are two official branches in Isar, intended to increase project
+quality:
+
+ - next: The accepted contributions from mailing list are merged to this
+   branch. Basic CI checks should be run after each merge. This branch
+   could be forced.
+
+ - master: After passing full-cycle testing of next branch, it should be
+   merged to master. Master branch should contain stable releases only, so
+   all the features officially supported by current Isar version (including
+   features from previous releases) should be tested.
+
+The next branch is intended to be merged into master monthly. Maintainer
+could perform a merge to master before the ordinary window if next branch
+contains urgent patch series (bug fixes or critical features).
+
+## Issues at GitHub
+
+For each issue has been found in master and next branches the maintainer
+should create GitHub issue.
-- 
2.9.4

Re: [PATCH] doc: Add maintainer process

[Henning Schild]

Am Mon, 28 Aug 2017 10:02:54 +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 | 47
> +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47
> insertions(+) create mode 100644 doc/maintainer.md
> 
> diff --git a/doc/maintainer.md b/doc/maintainer.md
> new file mode 100644
> index 0000000..ddaf39b
> --- /dev/null
> +++ b/doc/maintainer.md
> @@ -0,0 +1,47 @@
> +# Introduction
> +
> +Isar maintainer is the person who keeps project development in
The Isar mainteiner
who keeps the project dev

> compliance +with contributing process definition. The purpose of this
with the contributing

> document is to +describe the maintainer process in Isar project.

in the Isar project.

Two sentences and 4 missing articles. I will read the rest in v2.

Henning

> +
> +# Responsibilities
> +
> +## Feedback on Contributions
> +
> +Isar maintainer should review each contribution that has been sent to
> +mailing list and provide the feedback. Feedback could be on of the
> +following categories:
> +
> + - Contribution accepted: If no quality and design issues were found.
> +
> + - Change request: If some small quality or design issues were
> found, the
> +   maintainer requests next 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.
> +
> +## Repository Branches
> +
> +There are two official branches in Isar, intended to increase project
> +quality:
> +
> + - next: The accepted contributions from mailing list are merged to
> this
> +   branch. Basic CI checks should be run after each merge. This
> branch
> +   could be forced.
> +
> + - master: After passing full-cycle testing of next branch, it
> should be
> +   merged to master. Master branch should contain stable releases
> only, so
> +   all the features officially supported by current Isar version
> (including
> +   features from previous releases) should be tested.
> +
> +The next branch is intended to be merged into master monthly.
> Maintainer +could perform a merge to master before the ordinary
> window if next branch +contains urgent patch series (bug fixes or
> critical features). +
> +## Issues at GitHub
> +
> +For each issue has been found in master and next branches the
> maintainer +should create GitHub issue.

Re: [PATCH] doc: Add maintainer process

[Jan Kiszka]

On 2017-08-29 10:51, [ext] Henning Schild wrote:
> Am Mon, 28 Aug 2017 10:02:54 +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 | 47
>> +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47
>> insertions(+) create mode 100644 doc/maintainer.md
>>
>> diff --git a/doc/maintainer.md b/doc/maintainer.md
>> new file mode 100644
>> index 0000000..ddaf39b
>> --- /dev/null
>> +++ b/doc/maintainer.md
>> @@ -0,0 +1,47 @@
>> +# Introduction
>> +
>> +Isar maintainer is the person who keeps project development in
> The Isar mainteiner

maintainer

> who keeps the project dev
> 
>> compliance +with contributing process definition. The purpose of this
> with the contributing
> 
>> document is to +describe the maintainer process in Isar project.
> 
> in the Isar project.
> 
> Two sentences and 4 missing articles. I will read the rest in v2.

None of us is a native English speaker, and we are all influenced by our
mother tongue when making mistakes. Let's help each other sorting them out.

Jan

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

Re: [PATCH] doc: Add maintainer process

[Henning Schild]

Hey,

in general it is nice to have that document. It describes processes we
already have in place, but one essential point is missing.

In the review process it seems like the maintainer is the only one that
does reviews. It should be stated how the rest of the community can
join that process.

Henning


Am Mon, 28 Aug 2017 10:02:54 +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 | 47
> +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47
> insertions(+) create mode 100644 doc/maintainer.md
> 
> diff --git a/doc/maintainer.md b/doc/maintainer.md
> new file mode 100644
> index 0000000..ddaf39b
> --- /dev/null
> +++ b/doc/maintainer.md
> @@ -0,0 +1,47 @@
> +# Introduction
> +
> +Isar maintainer is the person who keeps project development in
> compliance +with contributing process definition. The purpose of this
> document is to +describe the maintainer process in Isar project.
> +
> +# Responsibilities
> +
> +## Feedback on Contributions
> +
> +Isar maintainer should review each contribution that has been sent to
The Isar maintainer
> +mailing list and provide the feedback. Feedback could be on of the
the mailing list
and provide feedback
Feeback could be out off the

> +following categories:
> +
> + - Contribution accepted: If no quality and design issues were found.
> +
> + - Change request: If some small quality or design issues were
> found, the
> +   maintainer requests next version with resolved issues.

requests a new version

> + - 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.
> +
> +## Repository Branches
> +
> +There are two official branches in Isar, intended to increase project
> +quality:
> +
> + - next: The accepted contributions from mailing list are merged to
> this
from the mailing list
 
> +   branch. Basic CI checks should be run after each merge. This
> branch
> +   could be forced.
>
> + - master: After passing full-cycle testing of next branch, it
> should be
> +   merged to master. Master branch should contain stable releases
> only, so
> +   all the features officially supported by current Isar version
> (including
> +   features from previous releases) should be tested.

I know what you want to say, how about?

- 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.
> Maintainer +could perform a merge to master before the ordinary
The maintainer could

> window if next branch +contains urgent patch series (bug fixes or
if the next branch
contains urgent patches

> critical features). +
> +## Issues at GitHub
> +
> +For each issue has been found in master and next branches the
issue that has been found
> maintainer +should create GitHub issue.

create a GitHub issue.