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
Re: Does it make sense to keep ~alpine/aports running?
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
Re: Does it make sense to keep ~alpine/aports running?
On Fri Mar 6, 2020 at 12:35 PM, Ariadne Conill wrote:
> 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.
The CI's are different and have different feature-sets. I am certain
that builds.sr.ht is perfectly suitable for aports CI.
Re: Does it make sense to keep ~alpine/aports running?
Hello,
On Fri, 2020-03-06 at 14:18 -0400, Timothy Legge wrote:
> 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.
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,> > > > 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
Re: Does it make sense to keep ~alpine/aports running?
Hello,
On Fri, 2020-03-06 at 14:18 -0400, Timothy Legge wrote:
> 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.
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,> > > > 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
Re: Does it make sense to keep ~alpine/aports running?
On Fri, 6 Mar 2020 12:35:33 -0500
Ariadne Conill <ariadne@dereferenced.org> wrote:
> > 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.
I asked in the #alpine-infra channel and they say that they don't have
the capacity or interest in either moving CI to build.sr.ht or run
double set of CI. We also don't have enough hardware for running two
sets of CI.
-nc