On 2019-01-23 6:51 AM, Mike Gran wrote: [...] > I don't think that would help. The challenge is that bug-fixing and > patch review isn't really where the maintainers' effort is right now. > Guix and Guile 3 are the major efforts. We don't need to make it > easier to submit patches. We need to make it easier to incorporate > patches. >
+1; I get this impression as well. > > Some projects (like Pixman) have a rule that if a patch receives no > opposition after a few weeks and a couple of pings, you are free to > push it. I wonder if that would work here? Or would it be too > chaotic? > I have an inkling that that could indeed end up being a bit chaotic. Though, if there are a few regular contributors that are really in sync and in tune with each other the likelihood of that may decrease. To go off on a tangent, I’d like to second Brett’s suggestion of looking into Drew DeVault’s sr.ht [1] instead of GitLab. As someone who’s used both the various “modern” JS-based in-browser tools and the good old email-driven workflows, I understand it may be a matter of preference, but I’d personally *hate* to get stuck having to use a slow and sluggish web app that uses the latest and shiniest trendy crappy JS framework of the day that eats up the entire 8GBs of memory on my computer. I much rather the comfort of my Gnus + (Ma)git-based workflows in GNU Emacs. What’s great about sr.ht is that it treats email as first class citizen, but also provides small and bloat-free web interfaces which are as JS-free as possible that expose some of the features to the users who prefer using their browsers. Though I think sr.ht still has ways to go to be a suitable replacement for Savannah, there’s already a lot work put into it and it’s looking really promising so far. I wonder if it would be a good idea at some point in the future to suggest it to the FSF sysadmins as a possible replacement/complement for Savannah. Regardless, it’d be great to have it evaluated [2] according to the GNU ethical repository criteria [3]. Footnotes: [1] https://sr.ht [2] https://www.gnu.org/software/repo-criteria-evaluation.html [3] https://www.gnu.org/software/repo-criteria.en.html