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