MIME-Version: 1.0
Date: Wed, 11 Mar 2020 17:23:37 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "Ariadne Conill" <ariadne@dereferenced.org>
Message-ID: <9aefd251cf029590dfe467ddeddb8127@dereferenced.org>
Subject: Re: Does it make sense to keep ~alpine/aports running?
To: "Ivan Tham" <pickfire@riseup.net>, ~alpine/devel@lists.alpinelinux.org
In-Reply-To: <20200311144046.ovfngbprmbnsugii@arch>
References: <20200311144046.ovfngbprmbnsugii@arch>
 <24b91bd507e8151d41ac1d9866a4fd7a07febfe0.camel@cogitri.dev>
 <20200310170643.7a475808@ncopa-desktop.copa.dup.pw>
 <3516641b-cade-47b1-9d53-6db5cac84032@localhost>
 <fb51b086-175c-99f1-2913-216fcb42bb0d@malikania.fr>

Hello,=0A=0AOn March 11, 2020 9:40 AM, "Ivan Tham" <pickfire@riseup.net> =
wrote:=0A=0A> On Wed, Mar 11, 2020 at 09:08:44AM +0100, David Demelier wr=
ote:=0A> =0A>> Le 11/03/2020 =C3=A0 00:23, Cosmo Borsky a =C3=A9crit :=0A=
>>> However, since there are a good amount of developers contributing pat=
ches to the aports list=0A>> =0A>> No, there are only few individuals. Mu=
ch lesser than GitLab.=0A> =0A> Yes, there may be only few individuals, b=
ut what if those few=0A> individuals are maintainers of some packages? Fo=
r example, I still=0A> prefer to submit version bumps and new packages th=
rough `git send-email`=0A> since using a browser for this is quite overki=
ll, unless I need someone=0A> to review then opening a browser for this m=
akes more sense.=0A> =0A>>> it makes sense to keep the list knowing that =
review may take time, and have developers/reviewers=0A>>> use the platfor=
m they are comfortable with until several pain points are resolved.=0A>> =
=0A>> There are no real reasons to have two ways to contribute to a proje=
ct.=0A>> It adds complexity, in-visibility and mess. You have to check tw=
o=0A>> systems to see if there are already people working on something or=
=0A>> not. Plus, many mails in the mailing list are not marked as =E2=80=
=9Cresolved=E2=80=9D=0A>> so you have to check the status of the patch in=
dividually to see if=0A>> the patch was incorporated or not. Mailing list=
 patches are=0A>> appropriate for software where you can easily make perf=
ect patches by=0A>> default but for Alpine ports it's quite uncommon that=
 submitted=0A>> APKBUILDs are perfect by default and minor adjustments ar=
e often=0A>> necessary ending with many v2, v3, v4 patches cluttering the=
 list.=0A>> =0A>> Alpine should have the simplest infrastructure and is b=
y far the=0A>> distribution where contributing is definitely the easiest =
right now=0A>> and I really would like to avoid a complicated infrastruct=
ure such as=0A>> Fedora has.=0A> =0A> Yes, those are what gitlab achieves=
 when a review is needed.=0A=0AThe reality of it is that all packages bei=
ng sponsored by a developer=0Afor inclusion need proper review.  This res=
ults in developers importing=0Ayour patches into Gitlab as MRs *anyway* s=
o we may do the review.=0A=0AThis division of labor is simply unrealistic=
, which is why few developers=0Alook at the aports list when looking for =
new packages and packagers to=0Asponsor.=0A=0AAriadne