On Dec 13, 2007, at 10:14, Les Mikesell wrote:
OK, I guess I never understood 'community development' to mean
'making a lot of clutter that shouldn't be saved', but your
description does make sense.
It doesn't. It means unproven members of the community should have
the same rights to develop as proven members of the community. It is
only the actual changes that need to be proven, not the people.
It also means that some organizations may want certain features that
won't make it into memcached proper. They should have tools that make
this easy, as well as make it easy to share these changes with other
organizations that also want this behavior.
For example, when I was working on the binary implementation, pretty
much the only way anyone could track my work was to download either a
series of patches or a tarball with them all applied. If anyone
wanted to contribute to this development, it'd basically involve
sending a patch to my patched tree.
I haven't used it, but I thought svk was designed to interact with
subversion in exactly this way - that is you can check out an svn
project as a mirror, then make a local branch for your work. Svk is
supposed to offer the same functionality as svn whether standalone
or with a mirrored svn checkout, but in the latter case when you
merge your branch changes back to the mirrored, checked out copy, it
also commits them back into the subversion repository.
http://www.bieberlabs.com/wordpress/svk-tutorials/
I'm not sure how this works if you initially have read-only rights
and later are granted commit access, but I'd expect it to work.
I've looked at svk somewhat, but the general approach is to take
something excessively complicated and not well suited to a task and
build upon it. It might be the only option, but it's not very well
suited to sharing work.
--
Dustin Sallings
