Switch to actively maintained Red-Black tree implementation? about diskv HOT 15 CLOSED

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

from diskv.

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

from diskv.

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.

from diskv.

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.

from diskv.

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

from diskv.

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?

from diskv.

Not much.

from diskv.

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...

from diskv.

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?

from diskv.

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 [email protected]
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
#28 (comment)

from diskv.

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.

from diskv.

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.

from diskv.

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.

from diskv.

Everything is built from source in Debian

I guess that explains it.

edit: I'm making these changes now.

from diskv.

Thank you very much! :)

from diskv.