[linux-elitists] Contributing to a Project with a Maintainer Who Doesn't Merge Contributions Quickly
Sat Jan 17 09:02:14 PST 2009
On Saturday 27 December 2008 00:12:43 Ben Finney wrote:
> Shlomi Fish <email@example.com> 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.
You assumed right.
> > 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.
Well, I'm not going to switch a distribution just to work on this project.
(Although installing it inside a VM is naturally an option.) But let's go on.
> * Install the necessary packages:
> $ sudo aptitude install bzr bzrtools bzr-svn svn
bzr is available for Mandriva Cooker but not bzr-svn:
# urpmi bzr-svn
No package named bzr-svn
So I tried to build it from source using python setup.py bdist_rpm, but ended
up running into this bug, which I reported:
Its importance was set to "low" and a maintainer says that:
I don't have much experience with RPMs nor do I have any RPM-based systems
though, so this isn't likely to get fixed unless somebody who does has a look.
So now I'll have to study the python setuptools just to fix the bzr-svn build.
> * 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/
You shouldn't have wasted time on writing all this, because I am not able to
use bzr in the first place.
In any case, I have some philosophical and hypothetical reservations on using
a private repository like that. For once, if I continue to work on several
changes, then afterwards I may have a lot of merging problems. It already
happened to me twice with this project that the svn checkout I had my changes
in, didn't merge cleanly due to formatting changes in the final version, which
I had to fix, and in one case the automated tests got broken.
Furthermore, if I keep a repository full of my own private changes that were
not integrated yet, and that I plan to submit one after the other, then it's
essentially a fork, and I'd like to avoid that.
And finally, I'm not sure it solves the problem of the large round-trip delay,
because dumping a huge patch with a sequence of many changes and commits is
not something that a maintainer will look upon fondly.
I may be finding non-existent flies in the ointment, and a distributed version
control system may be OK, but I still think it would be preferable to just get
a commit access.
Shlomi Fish http://www.shlomifish.org/
Best Introductory Programming Language - http://xrl.us/bjn84
<mauke> I'm not interested in what you're doing; what are you trying to
<PerlJam> mauke: I'm trying to achieve world peace and this regex is
the last thing standing in my way! ;)
More information about the linux-elitists