MIME-Version: 1.0
References: <C13S8HIQP137.22KA05RI10YLF@homura> <a1b36f583778cb14b50726289cb72a8d46b89d65.camel@cogitri.dev>
 <4c140756-b287-48a0-9d81-bc7421f72743@localhost>
In-Reply-To: <4c140756-b287-48a0-9d81-bc7421f72743@localhost>
From: Timothy Legge <timlegge@gmail.com>
Date: Fri, 6 Mar 2020 14:18:42 -0400
Message-ID: <CALTFL3X7f5CkxCfpc6sUAGVrffL2-hbPOOqOj3DWMjFOwrzfgg@mail.gmail.com>
Subject: Re: Does it make sense to keep ~alpine/aports running?
To: "~alpine/devel" <~alpine/devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"

Hi

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.

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.

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.

Tim


On Fri, Mar 6, 2020 at 1:35 PM Ariadne Conill <ariadne@dereferenced.org> wrote:
>
> Hello,
>
> On Mar 6, 2020 at 8:23 AM, Drew DeVault <sir@cmpwn.com> wrote:
>
> 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.
>
> The ticket doesn't show much, but there has been consistent progress on
> this for some time now. Here's the current workstream:
>
> https://github.com/libgit2/pygit2/pull/982
>
> 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.
>
> Ariadne