Re: moving to gitlab?

[Amin Bandali]

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