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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
