Date: Mon, 28 Oct 2019 03:31:07 +0000 (UTC)
From: Taner Tas <taner76@gmail.com>
Reply-To: Taner Tas <taner76@gmail.com>
To: ~alpine/devel@lists.alpinelinux.org, Rasmus Thomsen <oss@cogitri.dev>
Message-ID: <248468888.3068354.1572233467803@mail.yahoo.com>
In-Reply-To: <5152c7bd5e788aadfb987281a47107a4f3959860.camel@cogitri.dev>
References: <BXZLAL5IFNQW.15ACK4H0U6JGN@homura> <5152c7bd5e788aadfb987281a47107a4f3959860.camel@cogitri.dev>
Subject: Re: Alpine community governance
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_3068353_357195107.1572233467801"

------=_Part_3068353_357195107.1572233467801
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

 At least we can discus about some git hooks that easing maintainer PR's on testing repo. Since testing repo is enabled by user and regarding the purpose of this repo, this could be a feasible idea in my opinion.

    On Sunday, October 27, 2019, 4:42:45 PM GMT+3, Rasmus Thomsen <oss@cogitri.dev> wrote:  
 
 > Moving a discussion from IRC to the ML:
> 
> One easy way to improve the core team's bandwidth would be a simple
> git
> hook which allowed anyone to push changes to packages for which
> they're
> listed as the maintainer.

Hm, although that does sound like it'd significantly lessen the
workload on core member I dislike this approach, at least with how we
currently handle maintainership of packages. About everyone can become
a maintainer (which is a good thing IMHO since this allows people
knowing the package well but not Alpine's packaging process to be a
maintainer) as of now and I feel like it'd be best to have someone look
over the changes of maintainers which aren't that experienced with
Alpine's packaging process yet. Maybe just having somewhat strict CI
rules and only allowing a merge if CI passes would do the trick to
ensure QA is done though.

> This reduces the core team's workload to
> dealing with new packages, new maintainers, etc; but removes the
> burden
> of dealing with every change to aports.


  
------=_Part_3068353_357195107.1572233467801
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div class=3D"ydp8596beb0yahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px=
;"><div></div>
        <div dir=3D"ltr" data-setdir=3D"false">At least we can discus about=
 some git hooks that easing maintainer PR's on testing repo. Since testing =
repo is enabled by user and regarding the purpose of this repo, this could =
be a feasible idea in my opinion.<br></div><div><br></div>
       =20
        </div><div id=3D"ydpc72507f0yahoo_quoted_3207198481" class=3D"ydpc7=
2507f0yahoo_quoted">
            <div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
               =20
                <div>
                    On Sunday, October 27, 2019, 4:42:45 PM GMT+3, Rasmus T=
homsen &lt;oss@cogitri.dev&gt; wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div dir=3D"ltr">&gt; Moving a discussion from IRC to =
the ML:<br clear=3D"none">&gt; <br clear=3D"none">&gt; One easy way to impr=
ove the core team's bandwidth would be a simple<br clear=3D"none">&gt; git<=
br clear=3D"none">&gt; hook which allowed anyone to push changes to package=
s for which<br clear=3D"none">&gt; they're<br clear=3D"none">&gt; listed as=
 the maintainer.<br clear=3D"none"><br clear=3D"none">Hm, although that doe=
s sound like it'd significantly lessen the<br clear=3D"none">workload on co=
re member I dislike this approach, at least with how we<br clear=3D"none">c=
urrently handle maintainership of packages. About everyone can become<br cl=
ear=3D"none">a maintainer (which is a good thing IMHO since this allows peo=
ple<br clear=3D"none">knowing the package well but not Alpine's packaging p=
rocess to be a<br clear=3D"none">maintainer) as of now and I feel like it'd=
 be best to have someone look<br clear=3D"none">over the changes of maintai=
ners which aren't that experienced with<br clear=3D"none">Alpine's packagin=
g process yet. Maybe just having somewhat strict CI<br clear=3D"none">rules=
 and only allowing a merge if CI passes would do the trick to<br clear=3D"n=
one">ensure QA is done though.<div class=3D"ydpc72507f0yqt7995422698" id=3D=
"ydpc72507f0yqtfd40987"><br clear=3D"none"><br clear=3D"none">&gt; This red=
uces the core team's workload to<br clear=3D"none">&gt; dealing with new pa=
ckages, new maintainers, etc; but removes the<br clear=3D"none">&gt; burden=
<br clear=3D"none">&gt; of dealing with every change to aports.<br clear=3D=
"none"><br clear=3D"none"><br clear=3D"none"></div></div></div>
            </div>
        </div></body></html>
------=_Part_3068353_357195107.1572233467801--