Precedence: list
MIME-Version: 1.0
References: <20180726141558.2d451763@ncopa-desktop.copa.dup.pw>
In-Reply-To: <20180726141558.2d451763@ncopa-desktop.copa.dup.pw>
From: Carlo Landmeter <clandmeter@gmail.com>
Date: Mon, 30 Jul 2018 09:38:35 +0200
Message-ID: <CA+cSEmN91Cx9sQQg=Lk=_ppVVB4R49J9R-JEHwZjmeUDAYAm8Q@mail.gmail.com>
Subject: Re: [alpine-devel] How to improve quality control for patch reviews
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: Alpine-devel <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"

hi Natanael,
>
>
> - improve documentation. Write documentation with a simple checklist
>   you can look over before you submit a PR. For example, "check that
>   license is in SPDX format[1]",


This check has already been implemented. `apk add spdx-licenses-list`
should enable it.
We probably have to move this to main and make it a dep in abuild.

>
> "check that it does not automatically
>   start services from pre-install", etc. This will make it easier for
>   people doing patch reviews and can be useful when adding automated
>   checks.

We could add checks for this, but I don't see this very often so i
guess is case specific?

>
>
> - add more automatic checks


nmeum has started coding an abuild linter in go. He got some negative
remarks as it was
not written in some peoples favorite language which maybe stopped him
from ever finishing it?

>
>
> - give more people push access. Look for people that are candidates to
>   get push access. Help them to improve. Follow up when they are "good
>   enough".


The PR list is mostly populated by a handful of people. I think it
would be good if we look
at giving one or two commit access and keep an eye on their
contributions. It will save us
some time having to review simple contributions.

>
>
> Any other ideas or thoughts?
>

Regarding documentation, it think this is a task you (ncopa/fabled)
has to take on from your side.
Don't get me wrong, I'm not trying to criticize negatively but I think
its important that more
experienced people should show what Alpine as a project expects from a
given product/project
that extends to Alpine experience/functionality. Two major corner
stones of our project (build tools
and package manager) are heavily under documented and have been addressed as
"Read the source" too many times.
If infra team has to provide such facility to start creating
documentation this would be
no problem, but it does need follow up so it doesn't end up as a waste
of infra time.

-carlo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---