grub-devel
[Top][All Lists]
Advanced

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

Re: RFC: Grub project management


From: Eli Schwartz
Subject: Re: RFC: Grub project management
Date: Sat, 13 Feb 2021 20:05:11 -0500

On 2/12/21 11:00 PM, Glenn Washburn wrote:
> 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.

You can import mailing lists via mbox and switch over; I think you can
probably talk to sourcehut to figure out mirroring (I think by
subscribing a sourcehut mailing list to another mailing list)?

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

No, that's not "partly". That's just an argument against mailing lists.
They note that the ozlabs patchwork project does not know if a patch is
accepted or rejected, which is actually false -- you just need to update
the status separately. The sourcehut lists patchwork-equivalent supports
this, but also supports sending an X-Sourcehut-Patchset-Update header
when replying to the mailing list, to update a patch status (e.g.
"thanks, pulled"), and intends to eventually support automatically
detecting patches applied in git and mark them as applied.

"It is also hard to keep Patchwork in sync with multiple inboxes, so it
is not well suited to group maintainership."

I don't... even understand this sentence, so I couldn't judge its accuracy.

"Because of the mailing-list-based workflow, more spam has to be created
to give that feedback on the build and test status of patches. Patchwork
does show CI status but it is not necessarily obvious since it is also
buried in results for patches that are not relevant for various reasons."

I didn't realize for CI to give feedback via mail counts as "spam".
Aside for that, it's literally repeating the "patchwork bad because no
'patch is accepted' status". Which I've already pointed out is dead
wrong. Patchwork automatically filters out and default-hides patches
marked as applied, so you don't see them. A well-maintained patchwork
only shows pending patches (and their CI status too!) -- you just have
to, well, maintain it.

Overall, the ONLY conclusion I can come up with from your link is
"mailing lists are bad for development because patches via email are
distasteful". Which is a valid opinion for one to hold -- not everyone
likes mailing lists, not everyone *needs* to like mailing lists -- but
it's not really a useful opinion to try convincing people who like
mailing lists, to ditch them.

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

I doubt it. https://www.gnu.org/software/repo-criteria.html is rather
clear that requiring javascript for the site to work well is inherently
bad even if it's LibreJS-compliant (but is somewhat neutral on the topic
of whether optional, libre javascript for people who unfathomably *like*
it is evil)... and saying "well, we will never ever visit the site, only
use scripts to interact via the API" is quite missing the point, I'd
say. Do you expect people looking for CI status for patches to not visit
gitlab.com, only run a script to curl CI status over the API?

I'm not personally familiar with the captcha argument, and honestly, my
personal standards on multiple repo-criteria counts are lower than the
GNU or FSF projects. :)

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

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