GnuPG Github mirrors

[Daniel Kahn Gillmor]

On Wed 2015-10-28 14:58:38 -0400, RB wrote:
> GnuPG follows the same development process that existed for a large
> plurality of FOSS software prior to Github.  These models work, and
> have for literally decades before Github even existed; the only
> difference is the SCM has changed.

I agree with this, and i also prefer a patches-and-mail workflow for my
own work.  I'm happy that's an acceptable workflow within GnuPG.  But if
we count by number of users, there's probably an order of magnitude more
developers in existence today who understand github's standard workflow
than those who understand patches-and-mail.

Joshua was talking about writing a guide to help more people understand
patches-and-mail.  That's something you'd like to see happen, right?

I don't think any of us want patches-and-mail to be some sort of hazing
ritual, where learning the tools was so painful that we have to justify
it by thinking that the pain was necessary and anyone who hasn't
suffered accordingly is somehow unworthy.  Do we?  Hazing is generally a
silly and unfortunate squandering of resources and goodwill.

> It's amusing and frustrating to see a wave of developers insisting
> that any workflow but github must be backwards or nonexistent.

Some probably do make this claim; but many others simply don't know the
tools for an unfamiliar workflow.

Sometimes that's expressed as "the workflow i already know is more
intuitive".  This demonstrates a lack of imagination about how
intuitions are formed, i think, but it's hardly something to get snippy
about.  Let's welcome more developers and help them broaden their
intuitions, instead of telling folks to just RTFM.

> Emailed patchsets and communication prior to submission are a useful
> workflow, especially for tools that must necessarily be conservative
> in their development.  Just because you've gone through the motions of
> forking a project on github and making your changes does not entitle
> you to those changes moving upstream.

The selectivity of upstream patch adoption has little to do with
workflow choice.  You can have extremely conservative, rejection-heavy
(or ignore-heavy) projects on github.  And you can have extremely
permissive, we'll-accept-anything projects using patches-and-mail.

adoption of patches upstream should be gated on quality of the code and
the utility of the features added/bugs removed.  right?

What we shouldn't have is the workflow itself gating access to patch
submission.  That's just needless exclusion, and it's as limiting to the
projects that could get new contributions as it is to the would-be
contributors.

The kind of writeup Joshua proposed could help avoid that scenario.

> Communicate a little.

yes, agreed.  this is what we all want.  let's get more people
connected and communicating about the project.

Happy hacking,

          --dkg