State of Pidgin: Attracting and Maintaining New Contributors

[Ethan Blanton]

David Woodhouse wrote:
> I understand the argument that people should have the *choice* to use
> Mercurial, if they want to. I've no problem with choice.
> 
> I don't quite understand why anyone would *want* to use Mercurial, but
> fine. I am reminded of the line from Monty Python's Life of Brian — "we
> shall fight for his RIGHT to have babies!".

This is approximately how I feel about git vs mercurial, but the other
way around.  I understand that people should have the choice to use
git, but I cannot see why when mercurial is available.  ;-)

But after this, we largely agree.

> But really, the problem for Pidgin is exactly the opposite way round.
> At times it looks like we're being *forced* to use Mercurial, instead
> of the common tools that we're familiar with.
> 
> We are told that submitting patches by email or attaching them to
> tickets isn't acceptable and we *have* to make a PR in Bitbucket.

I agree that this is not optimal.

I understand where the policy comes from.  (We're buried and don't have
enough available developer effort.  I have approximately zero effort
available to contribute, for example)  However, I think a path for
accepting *quality patches* without requiring BitBucket PRs is probably
desirable ... if for no other reason than that the current BitBucket
UI is confusing for drive-by users.  (NB that I am aware that this is
part of the "git argument"; however, I spend a LOT more time at the
command line than on GitHub/BitBucket/etc.)

> When we do that using the common git-remote-hg tools, there are
> complicated Mercurial-specific things about branches vs. bookmarks
> which mean that the simple approach is "wrong". I think git-cinnabar
> improves that slightly but still I *think* I need to clone a completely
> new repo on bitbucket for each simultaneously open PR, because of the
> 'bookmark' vs. 'branch' thing.
> 
> There's no clear documentation on *how* to use the common and familiar
> tools to create an acceptable PR, which is hardly a good way to
> encourage drive-by contributions. 

I think this is the big problem.  I can see no reason whatsoever that
there should not be a reachable path from a native git repository
through some sort of hg connector to a workable pull request for a
casual developer.  The system models are not *that* different.

However, it will probably take someone with significant familiarity in
both systems to concoct the recipe.

So here's my call for contribution: can someone who has a good working
understanding of both Git and Mercurial identify and document a simple
workflow using a readily avialable git-to-hg connector to enable:

1) Simple cloning of the upstream repo
2) Native creation of git feature branches for "git-like" PRs on the
   git side
3) A single command push to BitBucket (perhaps using an alias)
   producing a sequence of revisions that can be directly PR'd

If there is some reason that this *cannot* be done, I suspect it is a
problem with the BitBucket interface for pull requests that we need to
bring to Atlassian's attention.  (Of course, who knows how far that
will go.)

> I work with other projects like LLVM which for legacy reasons aren't
> using git either. But there's an official git tree shadowing SVN, and
> it's relatively easy to submit patches. Nobody tells me "you MUST
> actually use subversion on the command line".

Ideally I think we should be able to accept patches with minimal
friction.  Certainly mercurial can import patches, and a volunteer
could turn patches into PRs with little effort.  Said volunteer
wouldn't even have to be a core developer, due to the nature of
hg/BitBucket.  There does remain the problem of making sure the
original author is plumbed into the PR loop with this solution,
however.

We accepted patches for many years with other version control systems.
It's not like there isn't precedent.

Ethan