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
