search

peterbourgon / diskv

A disk-backed key-value store.
http://godoc.org/github.com/peterbourgon/diskv
MIT License
1.41k stars 102 forks source link

Switch to actively maintained Red-Black tree implementation? #28

Closed onlyjob closed 8 years ago

onlyjob commented 8 years ago

I've noticed that github.com/petar/GoLLRB have no activity since 2013 while github.com/HuKeping/rbtree appears to be actively maintained.

I wonder if it would be worth switching to actively maintained project?

peterbourgon commented 8 years ago

Yes. I think https://github.com/google/btree might be a better candidate :) PR happily accepted!

onlyjob commented 8 years ago

google/btree have no Petar's copyright statement and its licensing status is unclear. If it is really based on petar/GoLLRB then how did it lost Petar Maymounkov's copyright and changed license to Apache-2.0? From licensing prospective I'm more confident with petar/GoLLRB.

As for pull request I can't, I can't (unless it is a trivial drop-in replacement). I have no time for this whatsoever, no skills in Golang and no ability to test.

peterbourgon commented 8 years ago

OK. While I'm not opposed to the suggestion, I have no impetus to swap out a working implementation, so I reckon we'll wait for a contributor.

onlyjob commented 8 years ago

On the other hand we already have google/btree in Debian so we should be good from licensing prospective.

onlyjob commented 8 years ago

google/btree suggests that it might be suitable for "drop-in replacement for gollrb trees"... How much effort you reckon might be necessary to try it?

peterbourgon commented 8 years ago

Not much.

onlyjob commented 8 years ago

It would be great if maybe you could try it then. If google/btree works out well it will be one less package to prepare and I would be able to introduce diskv to Debian ASAP...

peterbourgon commented 8 years ago

I don't understand your requests at all. Can you please provide me some more context? Why are you adding diskv, a Go source package, to Debian? Why does the last commit time of one of its dependencies represent a barrier to that effort?

jonboulle commented 8 years ago

AIUI, in order to package any Go projects for Debian, all dependencies need to be packaged as individual packages.

I'll try take a stab at this change myself if I can carve out some time...

On Wed, Mar 30, 2016 at 6:13 PM Peter Bourgon notifications@github.com wrote:

I don't understand your requests at all. Can you please provide me some more context? Why are you adding diskv, a Go source package, to Debian? Why does the last commit time of one of its dependencies represent a barrier to that effort?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/peterbourgon/diskv/issues/28#issuecomment-203507717

peterbourgon commented 8 years ago

I'm sure I'm being insufficiently creative, but that doesn't make sense to me. Adding a (binary) Go project to Debian presumably means uploading a statically-linked executable to a repository. Correct? In which case, its dependencies are baked-in, adding them separately to the same repository serves no obvious purpose.

onlyjob commented 8 years ago

Thanks, @jonboulle.

Why does the last commit time of one of its dependencies represent a barrier to that effort?

Just because we want to package healthy and maintained projects to avoid maintenance burden. I think here we are on the same page both upstream and downstream.

onlyjob commented 8 years ago

Everything is built from source in Debian so diskv will be introduced as source (-dev) package to satisfy build-time (not run-time) dependency. Statically linked executable will be built from source packages. I hope that make sense.

peterbourgon commented 8 years ago

Everything is built from source in Debian

I guess that explains it.

edit: I'm making these changes now.

peterbourgon commented 8 years ago

https://github.com/peterbourgon/diskv/releases/tag/v2.0.0

onlyjob commented 8 years ago

Thank you very much! :)