Re: [PATCH] doc: Add maintainer process

[Henning Schild <henning.schild@siemens.com>]

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.