grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Grub project management


From: Glenn Washburn
Subject: Re: RFC: Grub project management
Date: Fri, 12 Feb 2021 15:58:13 -0600

On Thu, 11 Feb 2021 23:50:38 -0500
Eli Schwartz <eschwartz@archlinux.org> wrote:

> On 2/11/21 10:53 PM, Glenn Washburn wrote:
> > For patches that people don't want to disappear on the list, I
> > think a merge request can help mitigate that. Also since the merge
> > request is effectively a whole commit tree, instead of some free
> > floating diffs, we can know precisely which commit its based off of
> > (master? or last stable?).
> > 
> > This is not intended to change the current patch submission
> > requirements for the project. Patches will still need to be sent to
> > the list and will be reviewed on the list. I think for non-trivial
> > patches it should be required to make a merge request as well so
> > that the CI passing is a requirement. I hope that by enforcing a
> > passing CI that maintainer and reviewer time is saved by ensuring
> > that patch series pass the sniff test.
> 
> Sending patches to both the mailing list and a gitlab repo "for CI
> purposes" seems confusingly redundant.
> 
> It would probably make more sense to use a patchwork configured to run
> CI on incoming patches, and maybe even respond to the mailing list
> with status reports.
> 
> e.g.
> 
> https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/20108
> 
> (Using a patchwork also prevents patches from disappearing!)

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

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

Glenn



reply via email to

[Prev in Thread] Current Thread [Next in Thread]