Date: Sat, 07 Mar 2020 10:45:24 +0000
To: Timothy Legge <timlegge@gmail.com>, ~alpine/devel <~alpine/devel@lists.alpinelinux.org>
From: Rasmus Thomsen <oss@cogitri.dev>
Reply-To: Rasmus Thomsen <oss@cogitri.dev>
Subject: Re: Does it make sense to keep ~alpine/aports running?
Message-ID: <ec59918e8d52c3b8444f8939649ee12fd97bde41.camel@cogitri.dev>
In-Reply-To: <CALTFL3X7f5CkxCfpc6sUAGVrffL2-hbPOOqOj3DWMjFOwrzfgg@mail.gmail.com>
References: <C13S8HIQP137.22KA05RI10YLF@homura>
 <a1b36f583778cb14b50726289cb72a8d46b89d65.camel@cogitri.dev>
 <4c140756-b287-48a0-9d81-bc7421f72743@localhost>
 <CALTFL3X7f5CkxCfpc6sUAGVrffL2-hbPOOqOj3DWMjFOwrzfgg@mail.gmail.com>
Feedback-ID: LZW2MXNaH7NSG88i8lGpebeqB0wmcl0-3TbzkSuzsmAwEQspn4GI-WRe8j3PhRL4SBmua4rQWq6fadPcLS5uxQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

On Fri, 2020-03-06 at 14:18 -0400, Timothy Legge wrote:
> Hi
>=20
> As a relative newcomer to the alpine scene and someone who has used
> github exclusively until the recent change to gitlab I do prefer the
> visibility of the github or gitlabs experience to past experiences
> dealing with mailing list for other things and it is how I work with
> most projects now.

Yes, the ML can be rather rough, especially for newcomers.

> Initially it does seem like a lot of overhead for a person who is
> submitting a single patch but more and more people are using these
> tools regularly so its not a big deal and once someone has gone
> through the initial effort they may stick around.

Yes, but the overhead of working with Gitlab can be greatly decreased
my using the Gitlab API. I'll go and see with Leo if we can make some
neat scripts for that for Alpine.

> The merge requests would certainly be longer to create than a mailing
> list email and they do sometimes linger there for longer than I would
> like (particularly for the abuild repo) but that seems to have
> improved as of late.

Ah yes, especially for abuild, apk-tools and mkinitfs MRs rot right
now, since only a more limit set of devs have push access for that. I
do hope that the situation for those will improve over time too.

> Tim


Regards,

Rasmus Thomsen
> On Fri, Mar 6, 2020 at 1:35 PM Ariadne Conill <
> ariadne@dereferenced.org> wrote:
> > Hello,
> >=20
> > On Mar 6, 2020 at 8:23 AM, Drew DeVault <sir@cmpwn.com> wrote:
> >=20
> > On Fri Mar 6, 2020 at 6:13 AM, Rasmus Thomsen wrote:
> > > * No CI. I see there's a todo for that in sr.ht and I don't mean
> > > to
> > > disrespect anyone's efforts - sr.ht is a lot better than other ML
> > > things for me already :), but we _still_ don't have CI on there,
> > > so I'm
> > > not exactly hopeful that we'll get it soon.
> >=20
> > The ticket doesn't show much, but there has been consistent
> > progress on
> > this for some time now. Here's the current workstream:
> >=20
> > https://github.com/libgit2/pygit2/pull/982
> >=20
> > A key point here that others have not raised is that this would
> > require either moving the gitlab CI to use builds.sr.ht or
> > maintaining two sets of CI.  I doubt either is truly worth it, as
> > the alternate CI is probably less featureful in gitlab.
> >=20
> > Ariadne