Developing memcached, how should we do it?
dustin at spy.net
Thu Dec 13 18:30:12 UTC 2007
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.
> 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.
More information about the memcached