Developing memcached, how should we do it?

[Les Mikesell]

Dustin Sallings 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.

But that's just an administrative issue at the repository level. All it 
takes is a branch with commit access.  And then other people who want 
the change don't have to track them down.

>     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.

Svn is pretty well suited for maintaining central control.  Whether the 
person who has that central control wants to give out commit access is a 
different question.

-- 
   Les Mikesell
    lesmikesell at gmail.com