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

[Shlomi Fish]

On Saturday 27 December 2008 00:12:43 Ben Finney wrote:
> 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.
>

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:

https://bugs.launchpad.net/bzr-svn/+bug/311712

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/
>
[SNIPPED]

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.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
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 
           achieve?
<PerlJam>  mauke: I'm trying to achieve world peace and this regex is
           the last thing standing in my way! ;)