From: Amin Bandali <bandali@gnu.org>
To: Mike Gran <spk121@yahoo.com>
Cc: "Aleix Conchillo Flaqué" <aconchillo@gmail.com>,
brettg@posteo.net, guile-devel <guile-devel@gnu.org>
Subject: Re: moving to gitlab?
Date: Thu, 24 Jan 2019 23:19:37 -0500 [thread overview]
Message-ID: <87ef911i92.fsf@aminb.org> (raw)
In-Reply-To: <20190123145123.GA15556@joshua.dnsalias.com> (Mike Gran's message of "Wed, 23 Jan 2019 06:51:23 -0800")
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
next prev parent reply other threads:[~2019-01-25 4:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 9:25 ping: Fixes for guile.m4 Alex Sassmannshausen
2019-01-21 14:42 ` Mike Gran
2019-01-22 7:44 ` alex sassmannshausen
2019-01-22 23:02 ` moving to gitlab? (was: Re: ping: Fixes for guile.m4) Aleix Conchillo Flaqué
2019-01-23 1:30 ` moving to gitlab? Greg Troxel
2019-01-23 2:12 ` Nala Ginrut
2019-01-23 4:18 ` Aleix Conchillo Flaqué
2019-01-23 14:51 ` Mike Gran
2019-01-25 4:19 ` Amin Bandali [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-01-23 3:10 brettg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ef911i92.fsf@aminb.org \
--to=bandali@gnu.org \
--cc=aconchillo@gmail.com \
--cc=brettg@posteo.net \
--cc=guile-devel@gnu.org \
--cc=spk121@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).