lunatechian (lunatech-ian)

one relating to, belonging to, or resembling lunatech

Contributing to a Project with a Maintainer Who Doesn't Merge Contributions Quickly

I saw this mail in one of the mailing lists I am on and thought it might be useful to a wider audience. This reply was given by Ben Finney

   I have some ambitious plans for enhancing the module, but I feel
   that it won't be practical to do it in the current conditions. I
   tried to soft-talk the maintainer into giving me repository access,
   but then the conversation got diverted into applying my latest
   patch, which he said he'd like to perform the next day. He didn't
   and it's been at least two weeks since then.

Since you talk about asking for “commit access”, I presume it's in an old-school centralised-only VCS. I'll assume Subversion.

What are your thoughts about a situation like this?

Use a distributed VCS to track your changes. I prefer Bazaar, so I'll discuss that below.

  • Use Debian GNU/Linux, ‘lenny’ or later.
  • Install the necessary packages: $ sudo aptitude install bzr bzrtools bzr-svn svn
  • Get a local Bazaar checkout of the upstream Subversion branch so you can track upstream's changes discretely and easily: $ bzr checkout svn+ssh://vcs.example.org/foo/trunk/ foo.trunk/
  • Bazaar uses the ‘bzr-svn’ plugin to work with Subversion repositories. It has its foibles, especially with writing to Subversion repositories; but for tracking an upstream Subversion repository against your Bazaar-managed branches, it's excellent.
  • Branch from upstream so you can track your changes: $ bzr branch foo.trunk/ foo.interesting-new-feature/
  • Work on your interesting new feature, committing often:
    $ cd foo.interesting-new-feature/
    $ emacs spam.py  # hack hack hack
    $ make test  # or however you run your full test suite
    $ bzr commit --message "One-line description"
  • When upstream has new revisions in their repository, update your checkout:
    $ cd foo.trunk/
    $ bzr update
  • When you want to send a patch of your current work against upstream, generate a Bazaar “merge directive” (a patch bundle):
    $ cd foo.interesting-new-feature/
    $ bzr send --output ../foo.interesting-new-feature.patch --no-bundle
  • This makes a patch against the parent of the current branch (by default, since no other branch is specified), which is the ?foo.trunk/? branch you originally branched from. The --no-bundle option turns off the ?patch bundle? blob, which would be useful to a Bazaar-using remote user to merge the resulting patch and have identical revisions to you. Since you'll be sending it to a Subversion user, that blob won't be useful to them so we disable it.
  • Send the ‘foo.interesting-new-feature.patch’ file to upstream attached to an email message that explains what the changes are.

The Bazaar documentation, both online at <http://bazaar-vcs.org/> and in the bzr help foo commands, is comprehensive and should fill the many gaps I've no doubt left from the above explanation.

Defined tags for this entry: