Hello list,
After a patch for a package I maintain was posted on ~alpine/aports
I was wondering if it really makes sense to keep ~alpine/aports and to
keep allowing users to contribute by sending patches per email.
Currently the ML (for patches) isn't a good experience for both users
(as in patch posters) and developers (as in reviewers with push
permissions). Most Alpine developers just ignore the ML since they
don't like working with it or because there's no CI on the thing,
requiring them to either repost the patch on Gitlab as MR (which is yet
again more effort) or to test it locally and hope it works on other
arches. Additionally, it's effort to keep up with two hubs where
patches arrive from and for me personally it's a combination of all
three of those.
As such we let a lot of patches rotting because only few devs end up
checking them out. This scares contributors away, since no one wants
their contributions to just sit around without anyone looking at them.
So I think while the mantra of allowing users to contribute the way
they want is very nice, I don't think users are having a good
experience (_either_) due to missing reviews (and missing CI...).
In my opinion it'd make most sense to just shut down ~alpine/aports and
require users to make patches on Gitlab, as that'd offer numerous
advantages:
* No more conflicts between patches from the ML and Gitlab, users
rarely check out the ML if they use Gitlab or the other way around
to see if there are patches around for what they're doing already. This
wastes contributor's time and demotivates them.
* Reviewing patches is _way_ nicer on Gitlab compared to the ML IMHO
* We actually have CI on MRs - as mentioned we currently have to repost
patches on Gitlab for CI, which makes patches on the ML even more
tedious.
* And devs actually use the thing! Most devs just ignore the ML (me
included) and only review and merge changes that are posted on Gitlab.
I personally do feel like it's fine to keep the MR for other things
like user support or the devel list (although that sees very little
participation, so maybe it's time to switch there too...), but
~alpine/aports really doesn't make sense to me anymore.
Regards,
Rasmus Thomsen
It takes me almost no time to send a patch to the mailing list, under 5
seconds every time. It's barely more work to send the patch than it is
to update a package in the first place. Updating it on GitLab
comparitively takes 5-10x longer - I have to make a branch, open my web
browser, log in, push the branch, back to the browser, click a bunch of
buttons... if the mailing lists are dropped then I'm probably going with
it as a contributor.
I've used it in the past as a contributor, and did find that the
patches I tried to send more or less went idle until I pinged someone
on IRC and explicitly asked for them to be reviewed. I switched to
Github, then Gitlab because I was specifically following the
example/trend set by the Alpine Devs, because I needed more
interaction and feedback to refine my own work.
I think Drew has a point though, if you want to fire off a patch and
forget, then the ML takes the least amount of time and effort to
contribute, and that's a benefit to some people.
On Thu, Mar 5, 2020 at 3:48 PM Drew DeVault <sir@cmpwn.com> wrote:
>> It takes me almost no time to send a patch to the mailing list, under 5> seconds every time. It's barely more work to send the patch than it is> to update a package in the first place. Updating it on GitLab> comparitively takes 5-10x longer - I have to make a branch, open my web> browser, log in, push the branch, back to the browser, click a bunch of> buttons... if the mailing lists are dropped then I'm probably going with> it as a contributor.
I must admit that I never have used it, but doesn't gitlab have support for accepting patches from email?
/Fredrik
________________________________________
From: ~alpine/devel <~alpine/devel@lists.alpinelinux.org> on behalf of Will Sinatra <wpsinatra@gmail.com>
Sent: Thursday, March 5, 2020 10:14 PM
To: Rasmus Thomsen
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Does it make sense to keep ~alpine/aports running?
I've used it in the past as a contributor, and did find that the
patches I tried to send more or less went idle until I pinged someone
on IRC and explicitly asked for them to be reviewed. I switched to
Github, then Gitlab because I was specifically following the
example/trend set by the Alpine Devs, because I needed more
interaction and feedback to refine my own work.
I think Drew has a point though, if you want to fire off a patch and
forget, then the ML takes the least amount of time and effort to
contribute, and that's a benefit to some people.
On Thu, Mar 5, 2020 at 3:48 PM Drew DeVault <sir@cmpwn.com> wrote:
>> It takes me almost no time to send a patch to the mailing list, under 5> seconds every time. It's barely more work to send the patch than it is> to update a package in the first place. Updating it on GitLab> comparitively takes 5-10x longer - I have to make a branch, open my web> browser, log in, push the branch, back to the browser, click a bunch of> buttons... if the mailing lists are dropped then I'm probably going with> it as a contributor.
We shouldn't be so hot on removing the lists if they are not getting attention.
If the mailing list goes unattended, pinging devs should be OK. If a contributor chooses to make a GitLab account and submit a patch as a PR, they should be able to. If a contributor would like to email a patch in, they should be able to.
This seems more like the mailing list is not used extensively by devs/maintainers because it does not fit their workflow, be it testing patches, merging patches, etc.
IMO, we should discuss what could be done to fit the developer's workflow and be more inclusive of those working on the mailing list.
I've started to adapt a workflow that caters to both systems: the ability to mail and test mailed-in patches, and the ability to ease submitting PRs in eg. GitLab.
Keep in mind the lists are powered by SourceHut, which is still in its early days.
If you have ideas that would improve mailing list flow, submit a PR to SourceHut.
Here is a task related to this thread:
https://todo.sr.ht/~sircmpwn/dispatch.sr.ht/29
Additionally, other Alpine lists are powered by SourceHut:
https://lists.alpinelinux.org/lists/~alpine
Hello,
FWIW I think it doesn't take me longer than 5 seconds to open a MR
either due to the Gitlab API. Right now I just do:
git checkout -b branch
<do changes and commit>
mkmkr
And it creates a MR for me with the title, description etc. set. I'll
see with Leo if we can get that script so much up to speed that others
can use it without much effort too, so Gitlab can fit the "quickly send
changes" criterium too. Admittedly, it'll still be a little more effort
to make the first patch (one has to create an account/login via OAuth,
fork the repo and set an API key), but that doesn't take too long and
in return one gets the advantages I've noticed in my first email on
Gitlab.
Regards,
Rasmus Thomsen
On Thu, 2020-03-05 at 15:46 -0500, Drew DeVault wrote:
> It takes me almost no time to send a patch to the mailing list, under> 5> seconds every time. It's barely more work to send the patch than it> is> to update a package in the first place. Updating it on GitLab> comparitively takes 5-10x longer - I have to make a branch, open my> web> browser, log in, push the branch, back to the browser, click a bunch> of> buttons... if the mailing lists are dropped then I'm probably going> with> it as a contributor.
Hello,
On Fri, 2020-03-06 at 00:30 +0000, Cosmo Borsky wrote:
> > We shouldn't be so hot on removing the lists if they are not getting> attention.> > If the mailing list goes unattended, pinging devs should be OK. If a> contributor chooses to make a GitLab account and submit a patch as a> PR, they should be able to. If a contributor would like to email a> patch in, they should be able to.
Well, I just took a look at the current state of ~alpine/aports to see
the amount of rotting patches and I think the whole "pinging devs"
thing doesn't really work too well. And even so, the ML places even
more workload on devs, due to missing CI, yet another workflow they
have to learn etc.
> This seems more like the mailing list is not used extensively by> devs/maintainers because it does not fit their workflow, be it> testing patches, merging patches, etc.
As mentioned in my first email, the main pain points are:
* 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.
* A second community hub. There honestly is no way around this if we do
want to keep the ML, it's just an annoying situation when you have to
check yet another place for patches/duplicates.
* Reviewing via ML really, really isn't nice - although SourceHut
apparently worked on that a little already, but I think it's still not
as nice as Gitlab with markdown formatting, diff suggestions etc.?
> IMO, we should discuss what could be done to fit the developer's> workflow and be more inclusive of those working on the mailing list.> I've started to adapt a workflow that caters to both systems: the> ability to mail and test mailed-in patches, and the ability to ease> submitting PRs in eg. GitLab.
I'm sorry, but Gitlab just floats my boat to be honest. So instead of
using the (for me) worse solution for reviewing patches, I just use
Gitlab. I haven't surveyed any other devs, but my best guess from the
very low participation rate of other devs on the ML I feel like most
devs are in the same position.
> Keep in mind the lists are powered by SourceHut, which is still in> its early days.> If you have ideas that would improve mailing list flow, submit a PR> to SourceHut.
Hm, I don't think I'd have suggestions that are worthwhile for
SourceHut since Gitlab already is close to the optimal hub for me, so
I'd probably just want it to be bent into yet another same looking git
community hub. I do appreciate that SourceHut has set out to do
something different and wants to appeal to people who have a different
workflow, but as mentioned Gitlab works just fine for me (and
apparently for most other devs too). I can't really think of a thing
that I super dislike on Gitlab, it fits my workflow well and reviewing
and merging patches is a pleasant experience (especially once we switch
over to Gitlab as being the upstream repo instead of g.a.o).
> Here is a task related to this thread:> https://todo.sr.ht/~sircmpwn/dispatch.sr.ht/29> Additionally, other Alpine lists are powered by SourceHut:> https://lists.alpinelinux.org/lists/~alpine
Yes, as noted in my first eMail I feel like it's worth keeping the
other lists, like users and devel, since the ML _is_ a (somewhat) good
format for discussions (although the participation rate on devel isn't
good either) and SourceHut _is_ nice for that. I just feel like patches
via the ML are just too much of a painpoint to keep right now and cause
frustration on both the user and developer side.
Regards,
Rasmus thomsen
Le 05/03/2020 à 21:44, Rasmus Thomsen a écrit :
> Hello list,> > After a patch for a package I maintain was posted on ~alpine/aports> I was wondering if it really makes sense to keep ~alpine/aports and to> keep allowing users to contribute by sending patches per email.> Currently the ML (for patches) isn't a good experience for both users> (as in patch posters) and developers (as in reviewers with push> permissions). Most Alpine developers just ignore the ML since they> don't like working with it or because there's no CI on the thing,> requiring them to either repost the patch on Gitlab as MR (which is yet> again more effort) or to test it locally and hope it works on other> arches. Additionally, it's effort to keep up with two hubs where> patches arrive from and for me personally it's a combination of all> three of those.> As such we let a lot of patches rotting because only few devs end up> checking them out. This scares contributors away, since no one wants> their contributions to just sit around without anyone looking at them.> So I think while the mantra of allowing users to contribute the way> they want is very nice, I don't think users are having a good> experience (_either_) due to missing reviews (and missing CI...).> > In my opinion it'd make most sense to just shut down ~alpine/aports and> require users to make patches on Gitlab, as that'd offer numerous> advantages:> > * No more conflicts between patches from the ML and Gitlab, users> rarely check out the ML if they use Gitlab or the other way around> to see if there are patches around for what they're doing already. This> wastes contributor's time and demotivates them.> > * Reviewing patches is _way_ nicer on Gitlab compared to the ML IMHO> > * We actually have CI on MRs - as mentioned we currently have to repost> patches on Gitlab for CI, which makes patches on the ML even more> tedious.> > * And devs actually use the thing! Most devs just ignore the ML (me> included) and only review and merge changes that are posted on Gitlab.
I completely second this proposal.
We should only keep one way to contribute to avoid complicated
processes. Also GitLab has the CI working and users are able to update
their merge request without having to send v2, v3, v4, v5, v6, etc new
revisions of patches.
Also, the mailing list system used does not send a mail back from the
original poster, which makes sometimes unconvenient to respond to your
own mail to add more information.
--
David
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
Hello,
> > On Mar 5, 2020 at 3:44 PM, Rasmus Thomsen <oss@cogitri.dev> wrote:> > > Hello list, After a patch for a package I maintain was posted on ~alpine/aports I was wondering if it really makes sense to keep ~alpine/aports and to keep allowing users to contribute by sending patches per email. Currently the ML (for patches) isn't a good experience for both users (as in patch posters) and developers (as in reviewers with push permissions). Most Alpine developers just ignore the ML since they don't like working with it or because there's no CI on the thing, requiring them to either repost the patch on Gitlab as MR (which is yet again more effort) or to test it locally and hope it works on other arches. Additionally, it's effort to keep up with two hubs where patches arrive from and for me personally it's a combination of all three of those. As such we let a lot of patches rotting because only few devs end up checking them out. This scares contributors away, since no one wants their contributions to just sit around without anyone looking at them. So I th
ink whil
e the mantra of allowing users to contribute the way they want is very nice, I don't think users are having a good experience (_either_) due to missing reviews (and missing CI...). In my opinion it'd make most sense to just shut down ~alpine/aports and require users to make patches on Gitlab, as that'd offer numerous advantages: * No more conflicts between patches from the ML and Gitlab, users rarely check out the ML if they use Gitlab or the other way around to see if there are patches around for what they're doing already. This wastes contributor's time and demotivates them. * Reviewing patches is _way_ nicer on Gitlab compared to the ML IMHO * We actually have CI on MRs - as mentioned we currently have to repost patches on Gitlab for CI, which makes patches on the ML even more tedious. * And devs actually use the thing! Most devs just ignore the ML (me included) and only review and merge changes that are posted on Gitlab. I personally do feel like it's fine to keep the MR
for othe
r things like user support or the devel list (although that sees very little participation, so maybe it's time to switch there too...), but ~alpine/aports really doesn't make sense to me anymore.
>
+1 on decommissioning the aports patch queue. Since people do not keep up on it, I don't think it's worth keeping. And it removes the primary dependency on mailing lists allowing us latitude to replace our current lists with a better solution, like Discourse.
Ariadne
On Fri, 6 Mar 2020 14:14:59 +0100
David Demelier <markand@malikania.fr> wrote:
> Also, the mailing list system used does not send a mail back from the > original poster, which makes sometimes unconvenient to respond to your > own mail to add more information.
There was some discussions about fixing this a month ago (before I went
to vacation).
Drew, what happened with this feature?
-nc
On Thu, 05 Mar 2020 15:46:11 -0500
"Drew DeVault" <sir@cmpwn.com> wrote:
> It takes me almost no time to send a patch to the mailing list, under 5> seconds every time. It's barely more work to send the patch than it is> to update a package in the first place. Updating it on GitLab> comparitively takes 5-10x longer - I have to make a branch, open my web> browser, log in, push the branch, back to the browser, click a bunch of> buttons... if the mailing lists are dropped then I'm probably going with> it as a contributor.
I have sent many patches to different upstream projects, and sending a
single trivial fix upstream using git send-email is by far the easiest
way (unless you are required to subscribe) when you deal with lots of
different upstreams.
However, some time ago sending patches by email was the only way to
contribute to Alpine and I was surprised that so many contributors had
problems sending email. Some of the issues was:
- figuring out how to set up SMTP host
- some email providers (gmail) modifies emails (inserts newlines etc),
resulting in patch does not applies.
- network policies at workplace that forbids SMTP traffic
Some also sent patches as attachment for some reason.
So while sending patches as emails is the easiest way for you, it
certainly is not the easiest for everyone.
-nc
On Tue Mar 10, 2020 at 2:56 PM, Natanael Copa wrote:
> So while sending patches as emails is the easiest way for you, it> certainly is not the easiest for everyone.
I never suggested dropping GitLab in favor of aports.
On Thu, 05 Mar 2020 20:44:23 +0000
Rasmus Thomsen <oss@cogitri.dev> wrote:
> I was wondering if it really makes sense to keep ~alpine/aports and to> keep allowing users to contribute by sending patches per email.
...
> In my opinion it'd make most sense to just shut down ~alpine/aports and> require users to make patches on Gitlab, as that'd offer numerous> advantages:> > * No more conflicts between patches from the ML and Gitlab, users> rarely check out the ML if they use Gitlab or the other way around> to see if there are patches around for what they're doing already. This> wastes contributor's time and demotivates them.
I think this is the key point.
> * Reviewing patches is _way_ nicer on Gitlab compared to the ML IMHO
I think reviewing patches via email is kind of nice. At least I used to
think so.
But I think gitlab (or github) is nicer when there are multiple
iterations. I have problems of keeping track of what patches has been
applied and which has not. Specially if there are a patchset with v2,
v3 patches.
> * We actually have CI on MRs - as mentioned we currently have to> repost patches on Gitlab for CI, which makes patches on the ML even> more tedious.
There is build.sr.ht but as mentioned in other emails, infra team does
not have resources or interest to either run two sets of CIs or move
gitlab CI to build.sr.ht.
> * And devs actually use the thing! Most devs just ignore the ML (me> included) and only review and merge changes that are posted on Gitlab.> > I personally do feel like it's fine to keep the MR for other things> like user support or the devel list (although that sees very little> participation, so maybe it's time to switch there too...), but> ~alpine/aports really doesn't make sense to me anymore.
So, one of the major reasons we kept a patch mailing list was because
there was people who would not contribute via github. I think the
majority of those are ok to contribute via gitlab, so that is not as
big problem nowdays.
I guess it boils down to if we want make it easy for contributors who
don't want sign up in gitlab, or prefers `git send-email` at the
expense of the reviewers. (and contributors who would need check both
mailing list and gitlab if someone else has provided same patch).
I think at this point, we need simplify the reviewing process rather
than simplify the submitting patches, since it currently is a bigger
problem to manage review the incoming patches than not having enough
contributions.
So I think it makes sense to shut down ~alpine/aports. Can we make it
read-only archives for now, and see how it goes? We can re-enable it if
it turns out to be a bad decision.
Carlo, what do you think?
-nc
Hi,
On 2020-03-10 17:13, Natanael Copa wrote:
> So, one of the major reasons we kept a patch mailing list was because> there was people who would not contribute via github. I think the> majority of those are ok to contribute via gitlab, so that is not as> big problem nowdays.> > I guess it boils down to if we want make it easy for contributors who> don't want sign up in gitlab, or prefers `git send-email` at the> expense of the reviewers. (and contributors who would need check both> mailing list and gitlab if someone else has provided same patch).
Do note that Gitlab supports sending patches and responding to issues
and MR's via email, there is just the problem that it's only available
in the enterprise edition of Gitlab.
1. reply by email [1]
2. new issue by email [2]
3. new merge request by email [3]
[1] https://docs.gitlab.com/ee/administration/reply_by_email.html
[2]
https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#new-issue-via-email
[3]
https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#new-merge-request-by-email-core-only
I personally do not think it's worth considering due to having to get a
Gitlab license and having to run proprietary code on the Alpine
infrastructure, but maybe opinions differ?
There is also a quite extensive GitLab API, I can imagine someone
writing a wrapper around it to allow using email with it.
Best regards,
Bart
If it makes any difference, I am willing to contribute time and resources for SourceHut related Alpine development.
I think it is good to keep to one platform. GitLab is a mature suite which is familiar to a lot of developers, although aspects of it are proprietary.
SourceHut is in alpha, still in (very) active development, and many pain points have been and are being alleviated, on top of it being full FOSS.
However, since there are a good amount of developers contributing patches to the aports list, it makes sense to keep the list knowing that review may take time, and have developers/reviewers use the platform they are comfortable with until several pain points are resolved.
It would be good to put together a comparison list between GitLab and SourceHut that covers what each platform does well, what could be worked on, and what it does not do well.
From this email thread, what I see as things that need to be worked on with SourceHut are:
- CI builds for patches submitted via list
- Fix compatibility with various hosts, eg Gmail
- Offer alternative methods for submitting patches, for example via web api if SMTP is blocked on a network.
GitLab has these pain points:
- Requires a user account
- requires submitting patches through merge requests, which has overhead (open web browser, fork, push changes to fork, ...)
- email-based workflow is proprietary and only included in enterprise editions
Le 11/03/2020 à 00:23, Cosmo Borsky a écrit :
> However, since there are a good amount of developers contributing patches to the aports list
No, there are only few individuals. Much lesser than GitLab.
> it makes sense to keep the list knowing that review may take time, and have developers/reviewers use the platform they are comfortable with until several pain points are resolved.
There are no real reasons to have two ways to contribute to a project.
It adds complexity, in-visibility and mess. You have to check two
systems to see if there are already people working on something or not.
Plus, many mails in the mailing list are not marked as “resolved” so you
have to check the status of the patch individually to see if the patch
was incorporated or not. Mailing list patches are appropriate for
software where you can easily make perfect patches by default but for
Alpine ports it's quite uncommon that submitted APKBUILDs are perfect by
default and minor adjustments are often necessary ending with many v2,
v3, v4 patches cluttering the list.
Alpine should have the simplest infrastructure and is by far the
distribution where contributing is definitely the easiest right now and
I really would like to avoid a complicated infrastructure such as Fedora
has.
> GitLab has these pain points:> - Requires a user account
Well, it's already needed to submit bugs so that's not a big deal IMHO.
> - requires submitting patches through merge requests, which has overhead (open web browser, fork, push changes to fork, ...)
GitLab has a public API, it could be handy to simply write a shell
script that creates them automatically. Rasmus Thomsen talked about
mkmkr in a previous mail.
--
David
On Wed, Mar 11, 2020 at 09:08:44AM +0100, David Demelier wrote:
>Le 11/03/2020 à 00:23, Cosmo Borsky a écrit :>>However, since there are a good amount of developers contributing patches to the aports list>>No, there are only few individuals. Much lesser than GitLab.
Yes, there may be only few individuals, but what if those few
individuals are maintainers of some packages? For example, I still
prefer to submit version bumps and new packages through `git send-email`
since using a browser for this is quite overkill, unless I need someone
to review then opening a browser for this makes more sense.
>>it makes sense to keep the list knowing that review may take time, and have developers/reviewers use the platform they are comfortable with until several pain points are resolved.>>There are no real reasons to have two ways to contribute to a project. >It adds complexity, in-visibility and mess. You have to check two >systems to see if there are already people working on something or >not. Plus, many mails in the mailing list are not marked as “resolved” >so you have to check the status of the patch individually to see if >the patch was incorporated or not. Mailing list patches are >appropriate for software where you can easily make perfect patches by >default but for Alpine ports it's quite uncommon that submitted >APKBUILDs are perfect by default and minor adjustments are often >necessary ending with many v2, v3, v4 patches cluttering the list.>>Alpine should have the simplest infrastructure and is by far the >distribution where contributing is definitely the easiest right now >and I really would like to avoid a complicated infrastructure such as >Fedora has.
Yes, those are what gitlab achieves when a review is needed.
>>GitLab has these pain points:>>- Requires a user account>>Well, it's already needed to submit bugs so that's not a big deal IMHO.>>>- requires submitting patches through merge requests, which has overhead (open web browser, fork, push changes to fork, ...)>>GitLab has a public API, it could be handy to simply write a shell >script that creates them automatically. Rasmus Thomsen talked about >mkmkr in a previous mail.
Oh, first time I have heard of mkmkr, maybe can take a look at it. Even
though I know these exists but still not as easily accessible as `git
send-email` in my humble opinion. Of course, setting up SMTP server is
one thing, but that is also another one time cost people invest in.
Hello,
On March 11, 2020 9:40 AM, "Ivan Tham" <pickfire@riseup.net> wrote:
> On Wed, Mar 11, 2020 at 09:08:44AM +0100, David Demelier wrote:> >> Le 11/03/2020 à 00:23, Cosmo Borsky a écrit :>>> However, since there are a good amount of developers contributing patches to the aports list>> >> No, there are only few individuals. Much lesser than GitLab.> > Yes, there may be only few individuals, but what if those few> individuals are maintainers of some packages? For example, I still> prefer to submit version bumps and new packages through `git send-email`> since using a browser for this is quite overkill, unless I need someone> to review then opening a browser for this makes more sense.> >>> it makes sense to keep the list knowing that review may take time, and have developers/reviewers>>> use the platform they are comfortable with until several pain points are resolved.>> >> There are no real reasons to have two ways to contribute to a project.>> It adds complexity, in-visibility and mess. You have to check two>> systems to see if there are already people working on something or>> not. Plus, many mails in the mailing list are not marked as “resolved”>> so you have to check the status of the patch individually to see if>> the patch was incorporated or not. Mailing list patches are>> appropriate for software where you can easily make perfect patches by>> default but for Alpine ports it's quite uncommon that submitted>> APKBUILDs are perfect by default and minor adjustments are often>> necessary ending with many v2, v3, v4 patches cluttering the list.>> >> Alpine should have the simplest infrastructure and is by far the>> distribution where contributing is definitely the easiest right now>> and I really would like to avoid a complicated infrastructure such as>> Fedora has.> > Yes, those are what gitlab achieves when a review is needed.
The reality of it is that all packages being sponsored by a developer
for inclusion need proper review. This results in developers importing
your patches into Gitlab as MRs *anyway* so we may do the review.
This division of labor is simply unrealistic, which is why few developers
look at the aports list when looking for new packages and packagers to
sponsor.
Ariadne
Hello,
On March 10, 2020 6:23 PM, "Cosmo Borsky" <me@cosmoborsky.com> wrote:
> If it makes any difference, I am willing to contribute time and resources for SourceHut related> Alpine development.
This is irrelevant. Without developers willing to sponsor packages
submitted via this channel, it will continue to be a second-class
citizen, which does not solve the fundamental problem with this
submission channel.
> I think it is good to keep to one platform. GitLab is a mature suite which is familiar to a lot of> developers, although aspects of it are proprietary.> SourceHut is in alpha, still in (very) active development, and many pain points have been and are> being alleviated, on top of it being full FOSS.> > However, since there are a good amount of developers contributing patches to the aports list, it> makes sense to keep the list knowing that review may take time, and have developers/reviewers use> the platform they are comfortable with until several pain points are resolved.
It really doesn't make sense. People duplicate effort and then get
upset that somebody else's package of the same thing is sponsored
over the version they submitted to the aports list. What makes sense
is to admit to ourselves that Gitlab is *the* platform moving forward
for getting packages in, via reviewed MRs.
> It would be good to put together a comparison list between GitLab and SourceHut that covers what> each platform does well, what could be worked on, and what it does not do well.> >> From this email thread, what I see as things that need to be worked on with SourceHut are:> > - CI builds for patches submitted via list> - Fix compatibility with various hosts, eg Gmail> - Offer alternative methods for submitting patches, for example via web api if SMTP is blocked on a> network.> > GitLab has these pain points:> - Requires a user account> - requires submitting patches through merge requests, which has overhead (open web browser, fork,> push changes to fork, ...)> - email-based workflow is proprietary and only included in enterprise editions
GitLab has an API. We are already planning on adding devscripts to
simplify the process of using GitLab so that you can stick to using
a CLI. I do not see signing up for an account to be a big deal,
especially considering that GitLab will likely serve as the basis of
single sign-on with other services inside Alpine in the future.
I also do not think the e-mail workflow is important. Almost all
research that I have done into these matters has concluded that
the overwhelming majority of Alpine contributors would like to get
rid of the mailing lists altogether in lieu of a more hybrid system
like Fedora has. We are still investigating options there, though.
Ariadne
On Wed, Mar 11, 2020 at 05:23:37PM +0000, Ariadne Conill wrote:
> Hello,> > On March 11, 2020 9:40 AM, "Ivan Tham" <pickfire@riseup.net> wrote:> > > On Wed, Mar 11, 2020 at 09:08:44AM +0100, David Demelier wrote:> > > >> Le 11/03/2020 à 00:23, Cosmo Borsky a écrit :> >>> However, since there are a good amount of developers contributing patches to the aports list> >> > >> No, there are only few individuals. Much lesser than GitLab.> > > > Yes, there may be only few individuals, but what if those few> > individuals are maintainers of some packages? For example, I still> > prefer to submit version bumps and new packages through `git send-email`> > since using a browser for this is quite overkill, unless I need someone> > to review then opening a browser for this makes more sense.> > > >>> it makes sense to keep the list knowing that review may take time, and have developers/reviewers> >>> use the platform they are comfortable with until several pain points are resolved.> >> > >> There are no real reasons to have two ways to contribute to a project.> >> It adds complexity, in-visibility and mess. You have to check two> >> systems to see if there are already people working on something or> >> not. Plus, many mails in the mailing list are not marked as “resolved”> >> so you have to check the status of the patch individually to see if> >> the patch was incorporated or not. Mailing list patches are> >> appropriate for software where you can easily make perfect patches by> >> default but for Alpine ports it's quite uncommon that submitted> >> APKBUILDs are perfect by default and minor adjustments are often> >> necessary ending with many v2, v3, v4 patches cluttering the list.> >> > >> Alpine should have the simplest infrastructure and is by far the> >> distribution where contributing is definitely the easiest right now> >> and I really would like to avoid a complicated infrastructure such as> >> Fedora has.> > > > Yes, those are what gitlab achieves when a review is needed.> > The reality of it is that all packages being sponsored by a developer> for inclusion need proper review. This results in developers importing> your patches into Gitlab as MRs *anyway* so we may do the review.> > This division of labor is simply unrealistic, which is why few developers> look at the aports list when looking for new packages and packagers to> sponsor.> > Ariadne
Just for the record, when I submit patches from the aports mailing list
to gitlab, it's not in order to review it, it's to have it run through a
CI system. If patches would hypotetically be run through a CI system, I
would not submit them as MR to gitlab.
Of course, that's just my situation, it might be different for others.