MIME-Version: 1.0
Date: Wed, 11 Mar 2020 17:34:59 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "Ariadne Conill" <ariadne@dereferenced.org>
Message-ID: <088013e8400374c798048728d100a8ed@dereferenced.org>
Subject: Re: Does it make sense to keep ~alpine/aports running?
To: "Cosmo Borsky" <me@cosmoborsky.com>,
 ~alpine/devel@lists.alpinelinux.org
In-Reply-To: <3516641b-cade-47b1-9d53-6db5cac84032@localhost>
References: <3516641b-cade-47b1-9d53-6db5cac84032@localhost>
 <24b91bd507e8151d41ac1d9866a4fd7a07febfe0.camel@cogitri.dev>
 <20200310170643.7a475808@ncopa-desktop.copa.dup.pw>

Hello,=0A=0AOn March 10, 2020 6:23 PM, "Cosmo Borsky" <me@cosmoborsky.com=
> wrote:=0A=0A> If it makes any difference, I am willing to contribute ti=
me and resources for SourceHut related=0A> Alpine development.=0A=0AThis =
is irrelevant.  Without developers willing to sponsor packages=0Asubmitte=
d via this channel, it will continue to be a second-class=0Acitizen, whic=
h does not solve the fundamental problem with this=0Asubmission channel.=
=0A=0A> I think it is good to keep to one platform. GitLab is a mature su=
ite which is familiar to a lot of=0A> developers, although aspects of it =
are proprietary.=0A> SourceHut is in alpha, still in (very) active develo=
pment, and many pain points have been and are=0A> being alleviated, on to=
p of it being full FOSS.=0A> =0A> However, since there are a good amount =
of developers contributing patches to the aports list, it=0A> makes sense=
 to keep the list knowing that review may take time, and have developers/=
reviewers use=0A> the platform they are comfortable with until several pa=
in points are resolved.=0A=0AIt really doesn't make sense.  People duplic=
ate effort and then get=0Aupset that somebody else's package of the same =
thing is sponsored=0Aover the version they submitted to the aports list. =
 What makes sense=0Ais to admit to ourselves that Gitlab is *the* platfor=
m moving forward=0Afor getting packages in, via reviewed MRs.=0A=0A> It w=
ould be good to put together a comparison list between GitLab and SourceH=
ut that covers what=0A> each platform does well, what could be worked on,=
 and what it does not do well.=0A> =0A>> From this email thread, what I s=
ee as things that need to be worked on with SourceHut are:=0A> =0A> - CI =
builds for patches submitted via list=0A> - Fix compatibility with variou=
s hosts, eg Gmail=0A> - Offer alternative methods for submitting patches,=
 for example via web api if SMTP is blocked on a=0A> network.=0A> =0A> Gi=
tLab has these pain points:=0A> - Requires a user account=0A> - requires =
submitting patches through merge requests, which has overhead (open web b=
rowser, fork,=0A> push changes to fork, ...)=0A> - email-based workflow i=
s proprietary and only included in enterprise editions=0A=0AGitLab has an=
 API.  We are already planning on adding devscripts to=0Asimplify the pro=
cess of using GitLab so that you can stick to using=0Aa CLI.  I do not se=
e signing up for an account to be a big deal,=0Aespecially considering th=
at GitLab will likely serve as the basis of=0Asingle sign-on with other s=
ervices inside Alpine in the future.=0A=0AI also do not think the e-mail =
workflow is important.  Almost all=0Aresearch that I have done into these=
 matters has concluded that=0Athe overwhelming majority of Alpine contrib=
utors would like to get=0Arid of the mailing lists altogether in lieu of =
a more hybrid system=0Alike Fedora has.  We are still investigating optio=
ns there, though.=0A=0AAriadne