Re: RFC: Grub project management

[Eli Schwartz]

On 2/12/21 4:58 PM, Glenn Washburn wrote:
> There are two main parts to this work, the CI and the merge request
> automation. As I see it, your issue is not with the CI, but the merge
> requests.

Yes -- CI is indeed wonderful to have and should be implemented if
possible (which it always is, therefore it should always be implemented).

> 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".

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

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...

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

OpenPGP_signature
Description: OpenPGP digital signature