+1 [As contributor, not committer]

> On Jul 1, 2016, at 9:42 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> 
> Hi Benedikt.
> 
> On Wed, 22 Jun 2016 10:43:08 +0000, Benedikt Ritter wrote:
>> Gilles <gil...@harfang.homelinux.org> schrieb am Di., 21. Juni 2016 um
>> 21:32 Uhr:
>> 
>>> Hello.
>>> 
>>> This is one of several votes for establishing new Commons components
>>> out of functionality developed inside the "Commons Math" component.
>>> 
>>> This vote is dedicated to the following functionality:
>>>   Representation of rational numbers
>>> 
>>> The concerned code is the contents of the following classes and
>>> packages:
>>>   org.apache.commons.math4.fraction
>>> located in the "develop" branch of Commons Math:
>>> 
>>> 
>>> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/fraction;h=446df46270ea0d00b7b23b603ca153df9ec18ffa;hb=refs/heads/develop
>>> 
>>> Notes:
>>>  * This component will depend on the "Standard math functions"
>>> component
>>>    (cf. other VOTE thread).
>>>  * Code size: ~1400 lines of code (unit tests not included).
>>>  * API: stable.
>>>  * Estimated minimum Java version: 5 (?)
>>> 
>>> All are welcome to vote, especially potential users of the candidate
>>> component and people who'd like to contribute to it, through user
>>> support,
>>> bug-fixes and enhancements, documentation, release management.
>>> 
>>> [ ] +1, this would be a valid Commons component.
>>> [ x ] -1, this won't be a good Commons component because ...
>>> 
>> 
>> Feels to much like a math component to me. Could better live in a Math TLP.
> 
> Since there is a similar functionality in Commons Lang, I would
> think that we'd either consider that it is common enough or that
> you think that it should be removed from Commons Lang.
> 
> Do you strongly oppose that Rob Tompkins tries to rationalize the
> implementations?
> [I assume that the goal would be to either have a new component
> (and deprecate the functionality in CL) or to validate and enhance
> the functionality in CL (ensuring that it is at least as complete,
> as accurate and as fast as the version in CM).]
> 
> As various people noted in the past months and weeks, it would not
> be nice to a new contributor to let him work and then not integrate
> it on the basis that this goal was not a consensus.
> 
> Thanks for reconsidering,
> Gilles
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org 
> <mailto:dev-h...@commons.apache.org>

Reply via email to