Developing memcached, how should we do it?

[Dustin Sallings]

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