What can / does commons provide that cannot be done with GitHub? chas
> On Feb 13, 2018, at 5:58 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > If this was a project to create specs AND provide reference implementations I > think it would make sense. I don’t see how a project that just creates specs > fits with Commons personally. > > Ralph > >> On Feb 13, 2018, at 1:46 PM, Matt Sicker <boa...@gmail.com> wrote: >> >> A sort of commons-algorithms type library? That kind of strikes me as what >> Commons is in the first place. I could see it being broken down into >> components, though. For example, commons-graph < >> https://commons.apache.org/sandbox/commons-graph/> (seems inactive) for >> graph algorithms, commons-tree for trees, heaps, and other similar ADTs and >> algorithms. Some ADTs already belong in commons-collections. Some >> algorithms may already be in commons-math, and there's efforts toward >> splitting that up into individual components (e.g., rng, numbers, >> statistics), so it doesn't make sense to group them in there IMO. >> >> On 13 February 2018 at 05:23, Bruno P. Kinoshita < >> brunodepau...@yahoo.com.br.invalid> wrote: >> >>> Hi Claude, >>> >>> Quite sure there was similar discussion some time ago. But I can't recall >>> if it was here in commons, somewhere in the incubator, or labs? >>> >>> But regarding commons, before the component/jira/mailing list are created, >>> I think it would have to go either via sandbox or incubator first? >>> >>> >>> Perhaps having some code somewhere like GitHub to show more or less the >>> concept would make it easier for others to evaluate the idea? >>> Cheers >>> Bruno >>> >>> >>> >>> >>> >>> ________________________________ >>> From: Claude Warren <cla...@xenei.com> >>> To: Commons Developers List <dev@commons.apache.org> >>> Sent: Tuesday, 13 February 2018 11:55 PM >>> Subject: Re: Discussion: New commons module/project >>> >>> >>> >>> The goal is arrive at a common understanding of the specific algorithm and >>> potentially one or more code examples for implementation which may be >>> pseudo code. >>> >>> I think all this requires is: >>> >>> 1. jira (or similar) to track the discussions and mark them when they >>> are closed >>> 2. A mechanism to list the algorithms that have been or are under >>> discussion. Perhaps the Jira search could provide this by default. >>> 3. A repository for code snippets. Though again perhaps Jira would be >>> sufficient. >>> 4. Mailing list in order to take votes and the like. >>> >>> Claude >>> >>> >>> >>> On Tue, Feb 13, 2018 at 10:31 AM, Bernd Eckenfels <e...@zusammenkunft.net> >>> wrote: >>> >>>> Hello, >>>> >>>> I am not sure how this might turn out, is it only discussion or do you >>>> also want to develop a specification language/toolset? In either case it >>>> does not sound like the typical commons sub-project. What infrastructure >>>> would you require? >>>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> ________________________________ >>>> From: Claude Warren <cla...@xenei.com> >>>> Sent: Tuesday, February 13, 2018 10:36:55 AM >>>> To: Commons Developers List >>>> Subject: Discussion: New commons module/project >>>> >>>> Disclaimer: I am not certain of the proper nomenclature to use here so >>>> when I say module consider that it may be a sub-project or project under >>>> commons. The term should be taken to mean a collection of the things >>> under >>>> discussion. >>>> >>>> I would like to propose a commons module for the development and >>>> documentation of algorithms. As anyone who has tried can attest, writing >>>> specifications that are not misunderstood is nigh on impossible. This >>>> module would provide an area to discuss various algorithms and work out >>>> code examples in various languages for implementation. >>>> >>>> For example: Bloom Filters. When creating a bloom filter you take the >>>> modulus of a digest to determine which bit in a bit vector to turn on. >>> But >>>> the modulus of a negative number is negative. So is it proper to take >>> the >>>> absolute value (abs) of the modulus or the digest or are you required to >>>> consider the digest to be a very long unsigned integer? All of these >>>> choices have repercussions and may impact interoperability. >>>> >>>> I have several co-workers and friends that are interested in exploring >>>> algorithms of this sort. Is there any interest here in starting such >>>> discussions? If so how does one go about it? >>>> >>>> I would like to see a ticketing system (Jira?) that discussions could be >>>> conducted against. So, for example, a single ticket for bloom filter >>>> implementation. The ticket would stay open until consensus was achieved. >>>> Once achieved the result would be documented and references to the >>>> discussion provided. >>>> >>>> Not clear on where to document the results and whether or not that >>>> documentation would include code. >>>> >>>> Thoughts? >>>> Claude >>>> >>>> >>>> -- >>>> I like: Like Like - The likeliest place on the web >>>> <http://like-like.xenei.com> >>>> LinkedIn: http://www.linkedin.com/in/claudewarren >>> >>>> >>> >>> >>> >>> -- >>> I like: Like Like - The likeliest place on the web >>> <http://like-like.xenei.com> >>> LinkedIn: http://www.linkedin.com/in/claudewarren >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
