Developing memcached, how should we do it?

[Trond Norbye]

dormando wrote:
>
> Good to finally hear from you folks! :) We were wondering what 
> happened. Were any patches necessary to integrate 1.2.2 into OpenSolaris?
>
Thank you :-)

We had to create some patches in order to integrate Memcached into 
OpenSolaris. We found some issues with libevent that had to be resolved, 
and those patches are already integrated in the community edition. We 
will create a patch for the modifications we did to the Memcached source 
and push it.

>
> I despise SVN. I do believe in restricting access to the main 
> repository, SVN does not make collaborative development very easy. I 
> personally use git while working on memcached. I import the repo via 
> git-svn, do all of my branch/etc work in native git, then `git-svn 
> dcommit` my data back to SVN when it's ready.
>
> I'd love to switch memcached _to_ git, but it'll take a little more 
> time and require more sign-on from the developers at large. Git isn't 
> very windows friendly, although it's nearly ubiquitous everywhere else.
>
> For your case I would recommend a local "centralized" git repository, 
> or elect one of you to be the local patch integration master. I 
> envision workflow a bit like this:
>
Ok. We want to do our development in the open, so I will go ahead and 
create a Mercurial repository on OpenSolaris.org (git is not available 
there). The sole purpose of this repository will be for our team to 
track (and exchange) our work, and we will push all relevant changes 
back to the community as soon as possible.


> I'll also take this time to re-iterate that frequently getting patches 
> integrated with upstream (ie; sending them to the list for review and 
> inclusion) will decrease the amount of pain required to integrate the 
> final product. I know you folks like "releasing" finalized things, but 
> you wouldn't do that to other programmers internally, so it makes 
> little sense to do that to us, too.
>
> Obviously there're exceptions such as withholding nonworking code, 
> branches that "might not make it", etc.
>

That is our intension.

Thanks,

Trond Norbye