GnuPG Github mirrors

[Jeroen Ooms]

On Tue, Oct 27, 2015 at 4:44 AM, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> You certainly have the right to do this under the GPL, but is it wise?

If nothing else it provides a nice way for Github users to monitor
GnuPG development by subscribing to the repo or via the API.

> Without community signoff your repo is going to be an unofficial mirror. People will file bug reports there and not on our bug tracker; worse, since you're the owner, they'll expect you to fix their issues.

The repo is entirely read-only, issues and wiki are currently
disabled. The mirror has been running for about 6 weeks and there have
been zero incidents of people trying to send patches.

Actually I also run a few other mirrors for much larger projects and
these experiences suggest that users and developers are, almost
without exception, sufficiently intelligent to find the original
developers. But if we ever encounter such and incident I'll make sure
to redirect those users to the official gnupg git server and mailing
lists.

> If the community decides to go the GitHub route, these problems go away. But I don't think you'll have much success with that until you clearly articulate *why* such a move is a good thing.  I currently have commit privs to the GnuPG FAQ, for instance, so convince me: why should I abandon a system that works well for GitHub?

I am not advocating GnuPG should move to Github. Obviously people have
strong opinions about this.

That said, the main argument why many open source projects enjoy
Github is because it makes it so much easier for others to get
involved and contribute, which catalyses development and discussion
around your project.

For example if I currently have a suggestion for a new GnuPG FAQ entry
I would have to download the code, create a patch, send that to the
mailing list, and then hope that you are actively reading the mailing
list, apply the patch and push. In Github I would simply clone the
repo, commit the changes, and send you a pull request in which we can
together review/discuss/tweak the changes until you are pleased and
merge. For a FAQ entry this might be minor, but for a significant code
overhaul this is a more powerful way to collaborate than emailing
patches.

Either way this discussion has been had dozens of times over the
internet, no need to repeat all arguments. In this video from earlier
this year, Daniel Stenberg (maintainer of libcurl) explains why he
decided to overcome skepticism and start accepting contributions from
Github users: https://youtu.be/ovVZtFoglOA?t=140 . This was six months
ago and there has been a significant increase in fixes and activity in
the project since then.