[linux-elitists] Contributing to a Project with a Maintainer Who Doesn't Merge Contributions Quickly

Ben Finney bignose+hates-spam@benfinney.id.au
Fri Dec 26 14:12:43 PST 2008


Shlomi Fish <shlomif@iglu.org.il> writes:

> 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.

* Repeat the steps of “branch to track discrete features”,
  “hack-test-commit”, “update your upstream checkout”, “make and
  send a patch bundle” whenever required.

The Bazaar documentation, both online at <URL: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.

-- 
 \            “Technology is neither good nor bad; nor is it neutral.” |
  `\                       —Melvin Kranzberg's First Law of Technology |
_o__)                                                                  |
Ben Finney



More information about the linux-elitists mailing list