Date: Thu, 26 Jul 2018 17:05:17 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Drew DeVault <sir@cmpwn.com>
Cc: Alpine Development <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] How to improve quality control for patch reviews
Message-ID: <20180726170517.670acc18@ncopa-desktop.copa.dup.pw>
In-Reply-To: <20180726122719.GB16298@homura.localdomain>
References: <20180726141558.2d451763@ncopa-desktop.copa.dup.pw>
	<20180726122719.GB16298@homura.localdomain>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 26 Jul 2018 08:27:20 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> Hey Natanael, I haven't been active much recently but I do have some
> thoughts here.
> 
> On 2018-07-26  2:15 PM, Natanael Copa wrote:
> > - 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]", "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.  
> 
> Docs are great but linters are much better (something you alluded to).

I was thinking docs could be helpful when implementing linter.
 
> > - add more automatic checks  
> 
> I'm working on a service, sr.ht[0], which provides a number of services
> including mailing lists[1] and continuous integration[2]. One feature I
> want to support is creating CI builds from patches sent to mailing lists
> (including off-site lists), and I already have a thing which can wire up
> GitHub pull requests to CI builds.
> 
> [0] https://sr.ht
> [1] https://lists.sr.ht/~sircmpwn
> [2] https://builds.sr.ht/job/5448
> 
> These builds could run in a fresh Alpine install (full virt with KVM)
> and attempt to build the package, catching any missing makedeps or
> ghostly dependencies like the example you gave suffered from, run a
> linter, and report the results back to the ML or the GitHub PR.
> 
> Would something like that be useful for Alpine?

I think this sounds like something we are looking for, but it may be
a bigger bigger question related. See
https://bugs.alpinelinux.org/issues/9134

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---