Contributing code..

[Lucas Gonzalez Pearson]

Hi All,
Does anyone here knows what's Mikio's involvement on this project?

We are willing to contribute code to the project but we haven't been
able to get in touch with Mikio to see how we can move forward...

thanks a lot,
Lucas

[Flinn Mueller]

I sent the patch here and cc'd his email address. My code wasn't accepted directly but he added similar code to satisfy the feature I was looking for. You might try that method. I've found he's hard to reach but I imagine like most he's busy.

> --
> You received this message because you are subscribed to the Google Groups "Tokyo Cabinet Users" group.
> To post to this group, send email to tokyocabi...@googlegroups.com.
> To unsubscribe from this group, send email to tokyocabinet-us...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tokyocabinet-users?hl=en.
>
>

[James Mansion]

Flinn Mueller wrote:
> I sent the patch here and cc'd his email address. My code wasn't accepted directly but he added similar code to satisfy the feature I was looking for. You might try that method. I've found he's hard to reach but I imagine like most he's busy.
>
>

Huh. I sent a patch and he said he wasn't interested in Windows
portability. I haven't got time to maintain a fork at the moment, so
I've dropped it. The fact that the author doesn't show up here *at all*
or discuss anything with us should tell something, eh?

James

[Martin Sarsale]

While I think Tokyo is a -great- project I have to say I'm pretty much worried about it going orphan. I don't think the project has a story long enough to say it can live without it's original developer; but I don't know the code so maybe ...

[Lucas Gonzalez Pearson]

I'm just worried about the same thing..
we will certainly back this up because part of our infrastructure
relies on tokyo, but the fact that Mikio is not behind this project is
also worrying us...

we are starting to think about forking....

[Flinn Mueller]

I didn't say your code would be merged if you sent it, I just suggested doing what worked for me might work for you. I get the sense this is a scratch your own itch project. It's not a large multi-developer/maintain effort to make the next generation of database. The author has to be selective in the code he will accept into the project (and ultimately be responsible for). It's GPL so nothing is stopping anyone here from maintaining their own flavored version of tokyo cabinet.

If he's not interested in making tokyo cabinet everything to everyone I'm fine with that. He's given us a working, real world example of a very fast h/v store. He doesn't owe us support or maintenance or even a subscription to this mailing list.

Just my take on it.

Cheers,
Flinn

[Flinn Mueller]

I don't disagree with that approach.  I think if Mikio is interested he will pick up the change eventually.

Also people have to take into account he's working on the successor to Tokyo Cabinet called Kyoto Cabinet - http://1978th.net/kyotocabinet/

Also for James one of the features of Kyoto Cabinet

• improves portability : abstraction of the lower layer to support non-POSIX systems.

[Arnaud Chong]

I'm worried about other things :
- The repository is not open. We don't have access to commit logs,
devel version, etc ...
- No open bug tracking
- There is no community around this project, except this mailing
list, without the only developer :)
- We don't know when a new version is released.

Arnaud

[Daniel Schaffer]

Is there a way as a group that we can keep Tokyo Cabinet active/developed/supported in a robust/dependable way?  It's an important piece of software for our efforts.

Dan Schaffer
National Oceanic and Atmospheric Administration
Boulder, CO

[Andy Mikhailenko]

I think it is possible to do the following:

1. maintain a public repository to which all Mikio's packages would be
automatically (or manually) imported with release notes as commit
messages. Of course such bulk commits are not very useful but at least
they help understand what's going on.
2. maintain a community fork of TC (and of TT) to which the above-
mentioned original commits would be continuously merged along with
code from various developers.

The first option does not involve much effort. The second one does.
But anyway it is important to make the development more transparent.

[Steve Conover]

This is my main worry about Tokyo as well. Mikio is pretty
unresponsive and emailing patches around is just silly. From a point
of view of "should I make a technology bet on tokyo" on a nontrivial
project, this is a pretty significant knock against it.

Ideally some heroic figure from the existing tokyo community would
take matters into their own hands and run a tokyo project on github,
and this would be the go-to place for contributions and filing issues
and such. What Andy outlined.

Sorry to be so blunt but I've been watching the tokyo community stuck
in this mode for the last 9+ months and it is very frustrating. It's
really too bad - the buzz and energy around tokyo is totally out of
joint with how the project is led. That said, all props to Mikio for
a great piece of technology.

-Steve

[Alex Popescu]

I have expressed the same concern the moment I heard about Kyoto
Cabinet
(http://nosql.mypopescu.com/post/345656500/kyoto-cabinet-the-successor-
of-tokyo-cabinet).

As I wanted to keep the NoSQL community informed I've sent an email to
Tokyo/Kyoto Cabinet
author asking politely to comment on the future of the two projects.
Unfortunately, I've never heard back on that.

As someone that has been involved in quite a few open source projects
in the past, I think
the way to address this issue is by continuing to contact the main
author and express your
concerns, trying to contact other project developers (while covering
Tokyo Cabinet on MyNoSQL
I have heard the name of Toru Maesaka) and as a last resort you could
probably fork the project
making it more open.

:- alex

MyNoSQL: Everything about NoSQL
http://nosql.mypopescu.com