On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren <[email protected]> wrote: > Actually the code I was thinking of is the multi-filter branch. It cleans > up some names and simplifies a few things. The collections and storage > packages might be best added as examples rather than as mainline code. > > In this case we just provide the bloom filter implementation, If we want > to provide the container implementation then I think it should probably be > modified to accept any SortedSet or NavigatableSet in the constructor. > > When I return home, next week, I'll take a swipe at moving the packages > over to org.apache.commons.collections4.bloomfilter package (unless there > is a better package name). We can then look at the entire code donation > and decide what changes need to be made before it is accepted. > > Does this sound like a reasonable approach?
Sounds reasonable to me - then it's easy to see what will be the code donation, they could be examples at first that we can link to from documentation, several commons packages have such example codes. Perhaps use packagename "commons.collections4.bloomfilter" without org.apache before it's been IP-cleared? Alternatively add it on a fork of https://github.com/apache/commons-collections/ so we don't confuse anyone. I see on your branch you are using some new dependencies like org.xenei.blockstorage and org.xenei.spanbuffer.SpanBuffer - would these be needed as well if we include the container implementation or are they more for disk-based collections? -- Stian Soiland-Reyes https://orcid.org/0000-0001-9842-9718 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
