[Twisted-Python] Twisted Project Jobs Volunteer

[Tim Allen]

On Mon, Nov 14, 2011 at 12:22:59AM -0500, Glyph wrote:
> Tim: you're right that there isn't much interest among the current
> Twisted core development team.  But the whole point of having a Git
> mirror (and a presence on Github, which I think is the next step) is
> to attract new developers to this community.
> 
> That's why the topic of this thread is "Twisted Project Jobs
> Volunteer".  We're asking for someone with expertise in this area to
> step up, volunteer to help maintain this mirror, which should help us
> attract more people who are interested in the same going forward.

There is a thing here that worries me, although I'm not sure I can
express it clearly without sounding crazy.

Back in the days when CVS and SVN were king, the only way you could
interact with a project was by submitting patches, and since only
commiters interacted directly with the master repository, it didn't
really matter much how branches and merges were handled. As long as you
kept things in a way that made sense to you, that was OK - nobody else
would see it.

Since Git is a distributed VCS, suddenly everybody has access to
everybody else's repositories, up close and personal, and suddenly (like
when any subjective matter is discussed by a large group of people),
people have *opinions* about other people's repositories, and there are
*fashions* and *best practices* and all that stuff. 

I'm not a Github user myself, so I don't know this first hand, but I as
I understand it the Github community is has even more social
expectations, like pull requests and the Github issue tracker.

It's very well to say "make git mirror, push to Github, get new
contributors", but I think there's a social impedance mismatch here
that's going to cause problems, or at least make people wary because
Twisted's Github project behaves weirdly and differently from other
Github projects they're used to.

Some examples that I can think of:
- The most obvious example: in Git, when you merge a branch to trunk,
  you get a merge commit; in SVN (at least the way Twisted uses it) you
  just get an ordinary commit that squashes together all the branch
  commits. That's not a technical problem, but the difference between
  the Twisted commit graph and an ordinary commit graph is
  a "something's not right" warning.
- In Git, the cultural expectation is "submit a sequence of patches";
  Twisted generally wants all your changes in a single patch, since the
  divisions will be lost on merge anyway.
- In Git, if I develop on a branch, then submit that branch as a patch
  sequence that gets applied by the repository owner, there's a good
  chance that when I 'git pull', git will recognise those patches as
  'my' patches and can rebase my branch intelligently. When those
  patches have gone via git svn, they seem to have changed enough that
  rebasing my branch causes horrible merge conflicts.
- In Git, you'd generally only create one branch for a patch series, and
  occasionally rebase it to keep up with trunk changes. The Twisted
  process seems to favour creating completely new branches (foo-1234,
  foo-1234-2, foo-1234-3, etc.) to handle trunk changes.
- As mentioned, Github merge requests and the Github issue tracker.

None of these are show stoppers, they're annoyances at worst, and could
be easily explained in documentation. But who will write that
documentation? Who will tirelessly explain the differences between the
Git world and the Twisted world on the mailing list and #twisted, poll
for merge requests and redirect them to Trac, forever?

TL;DR: Github users have expectations of how to interact with projects.
Twisted can make it easy for Github users to contribute by meeting those
expectations, switching from SVN to Git, and changing the UQDS to match.
Keeping things the way they are and adding a Git mirror is probably not
going to have the desired effect without a lot of effort on somebody's
part.

> Is that person you?  You're already maintaining the wiki page - and
> your participation in this thread has probably taken more time than
> the setup would have, if you have the relevant knowledge :).  Is there
> something you're missing?  Some administrative credential, perhaps?
> Information about where the relevant code lives?  If you're up for
> continuing on this, I'm sure we can get you whatever you need :).

Updating a wiki-page is not terribly onerous because it's bounded: solve
a problem by reading some documentation, write some more documentation,
done. Being the liaison between Twisted core developers and every Git
user who might want to contribute is unbounded... or at least, very
large and always growing as the number of Twisted devs and Git users
increases.

I've not forgotten that I have/had Twisted commit access, and coming
back to help on a more regular basis is definitely on my list of things
to do, although it's pushed down a fair way at the moment.  However,
even "volunteer for Twisted" was right at the top of the list, I'd be
a mug to sign up for such an open-ended responsibility. :)