Re: RFC: Grub project management

[Glenn Washburn]

On Fri, 12 Feb 2021 17:35:05 -0500
Eli Schwartz <eschwartz@archlinux.org> wrote:

> On 2/12/21 4:58 PM, Glenn Washburn wrote:
> > And you're right the merge request part is not ideal. There
> > is redundancy, but I don't think its that big of a deal. There does
> > come more confusion when determining what patch series version the
> > merge request is currently at and testing. This could be mitigated
> > by having the title of the merge updated when the merge branch is
> > updated or editing the merge request to use a new branch of the
> > changes which has the version number in its name. Sure a few extra
> > steps, but I don't see it as too much to ask. Plus, we're putting
> > the responsibility on the merge author and not project maintainers.
> > And yes, someone can in bad faith abuse the system to waste
> > maintainer time, but they'll quickly be rooted out.
> > 
> > Also, I was looking for a solution that didn't require me hosting
> > anything and I don't know of a free hosted patchwork service. It
> > looks like sourcehut fits the bill. Now I'm curious if there's a
> > reason that GRUB isn't already using that service, even if
> > unofficially. Perhaps, I'll look in to switching to that service.
> 
> https://libreplanet.org/wiki/FSF_2020_forge_evaluation
> 
> There are several interesting options for "we can do better than
> savannah these days". Sourcehut is one of the software forges under
> review.
> 
> However as far as I know, there's no unified approach to this, so the
> real question reduces back down to "why isn't there something,
> regardless of what" -- and the answer is likely something along the
> lines of "no one pushed for it, therefore inertia".

I poked around on a sourcehut account a little and its not obvious that
can can integrate with an existing mailing list. It looks like it
expects to host the mailinglist. I'm thinking there might be a way to
configure it act like a peer mailinglist, where it would receive
email from grub-devel and emails it received would be sent to
grub-devel.

Reading more about patchwork, it seems to have its own set of issues,
partly revolving around using a mailing list of development as we do.
see: https://lwn.net/Articles/773456/

> Aside: the evaluation is *very* critical of gitlab.com, though it
> considers self-hosted gitlab CE should alleviate a bunch of the listed
> concerns.

That evaluation wasn't clear on where the captcha was used. I can't
recall ever seeing a captcha on their site, certainly not on a regular
basis. I wonder how hard the GNU position would be against using GitLab
in the manner I suggest (modifying my original comment about requiring
merge requests for CI, but having it optional). Most of their
complaints seem to be around javascript. Would that be alleviated by
using scripts to do things via the API?

> sourcehut and pagure are the likely contenders for a GNU/FSF endorsed
> forge, and sourcehut is the only software forge I'm aware of
> *anywhere* that considers mailing lists to be a/the core development
> workflow (and therefore integrates a patchwork).
>
> > I think a lot of the work done in my GitLab CI changes could be
> > reused for other CI systems or we can use just the CI part of these
> > changes. That GitLab repo should be setup already to trigger a CI
> > pipeline whenever master changes (but only once the .gitlab-ci.yml
> > file is in master).
> 
> Yeah, having a somewhat independent script to run CI builds is good,
> it helps avoid getting locked into specific CI providers. :)
> 
> As we've seen from e.g.
> 
> https://www.theregister.com/2020/11/02/travis_ci_pricng/
> https://news.ycombinator.com/item?id=25338983
> 
> Free CI is not guaranteed to stick around...

Nope, nothing is. But GitLab's may last longer than others that have CI
as a core business.