[linux-elitists] Contributing to a Project with a Maintainer Who Doesn't Merge Contributions Quickly
Sat Jan 17 10:22:38 PST 2009
begin Shlomi Fish quotation of Sat, Jan 17, 2009 at 07:02:14PM +0200:
> So now I'll have to study the python setuptools just to fix the bzr-svn build.
There's always git, which is a DVCS with fewer
dependencies, mostly in portable C. (Now a
mix of C and shell, with a little Perl, they're
rewriting more and more of it in C every release.
Other dependencies: zlib, openssl, libcurl, ssh,
expat; plus Tcl/Tk if you want gitk and git-gui)
> In any case, I have some philosophical and hypothetical reservations on using
> a private repository like that.
You don't have to think hypothetically about this
stuff -- you could find one of the projects using a
DVCS (list for git here:
) and lurk on the mailing list. It seems like the
problems you describe come up often, and DVCS users
are using a variety of approaches, technical and
social, to handle them.
> 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.
But you get to draw a groovy graph of all the
micro-forks and re-merges!
The original post in this thread got two independent
replies, from Asheesh Laroia and Ben Finney, both
suggesting going DVCS and letting the "maintainer"
catch up if he or she wants to. I know there a lot
of projects that are starting with or moving to DVCS
culture, but anyone know of an example in the wild
of DVCS sedition in an existing CVS/SVN-based project?
Don Marti +1 510-814-0932
http://zgp.org/~dmarti/ +1 510-332-1587 mobile
See you at OpenSource World: August 10-13, 2009 in San Francisco
More information about the linux-elitists