commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: Need for an alternatives to the main line of code.
Date Fri, 23 Aug 2013 22:51:31 GMT
On 8/21/13 3:07 PM, Bernd Eckenfels wrote:
> Hello,
>
> "but those who propose it must be ready to perform a _committer_ work"
>
> I wonder if this is correct, this is after all (a somewhat annoyingly broad) discussion
list. If somebody suggest a new API/Structure and backs it up even with some working proof
of concept code (which better explains the concept and explains some points people questioned)
then this is a good and huge contribution even if it fails the policy requirements at first.
And it is possible that other (non comitters) can improve it from there. No proofs or unit
tests are mandatory at this (discussion) state. 
>
> But of course nobody can expect such draft work to be committed - but it might find a
champion who is convinced by its idea and partial existing work.
>
> In fact it is much better to have a API proposal which can be adopted to further proposals/clarifications
without throwing away documentation/test fluff.
>
> And on a unrelated topic - it is not a problem that there is no open SVN repo at this
stage. Neigther a policy controlled hosted repo nor SVN are good for the gradual,
> distributed brainstorming.
>
> BTW: why is a Optimizer/Algebra System/Math Library a commons project anyway?

You can still see the original proposal linked on the [math] project
page [1].  The basic rationale for the component has not really
changed over the 10 years that we have been working on it here.  We
have talked a few times about "graduating" but the great help and
feedback that we get from members of the commons community has
always outweighed the advantages of going TLP.  Of course, we live
in fear that after too many threads like this, we will eventually
get kicked out ;)

Phil

[1] http://commons.apache.org/proper/commons-math/proposal.html


>
> Greetings
> Bernd
>
> PS: nudge nudge, some feedback the questions I raised in the VFS threads would be great
;)
>
> Am 21.08.2013 um 23:47 schrieb Gilles<gilles@harfang.homelinux.org>:
>
>> On Wed, 21 Aug 2013 09:42:09 -0700, Ajo Fod wrote:
>>> Good for you...
>>>
>>> Yes just imagine if I'd to get every fix through committers. I'd never get
>>> anything done here.
>> Not every fix; commit to start with one.
>> I've spent a _lot_ of time detailing what you could do to go forward
>> with the issues which you submitted. And you simply ignored it all,
>> plainly saying that I'm free to do the work myself.
>>
>>>> On the subject of this thread: I did not imply that an "experimental"
>>>> package would allow sloppy or undocumented code or bypass unit testing.
>>>> All (the above) things being equal, the purpose would be to compare
>>>> alternative designs.
>>>>
>>> Perhaps I was not clear. Once again I repeat: I agree with the need for
>>> comments clean code and unit tests demonstrate the incremental utility of
>>> the contribution in the "experimental" package.
>> And you have been very clear that you expect other people to do the work.
>>
>>> I merely disagree that all contributors have the knowledge or the
>>> incentives to test "Everything (ideally)", reuse other Commons components,
>>> comment on "Everything", and in the case of CM analytically prove that the
>>> underlying math is sound, analyze when the code might fail, compare it with
>>> all other known methods, etc. So, if "half-baked" code (that solves a known
>>> problem) exists in the experimental packages, people who really need it to
>>> be reliably tested can patch in the tests and promote the code to
>>> "fully-baked" status.
>> I think that there exist projects out there that collect any code that
>> purports to solve some problem.
>>
>>> I hope you'll agree that as it stands, this makes CM capable of only
>>> solving a subset the mathematical problems of what it can solve with a more
>>> open policy.
>> I think that you are wrong. Even as we try to abide by rules, cruft
>> and bugs accumulate; loosening the policy will just make it worse.
>>
>> Phil explained the policy for Apache Commons projects. Personally, I've
>> also my reservations about some ill-defined aspects of the policy. But
>> I'm certainly not backing a proposal that amounts to unbounded maintenance
>> work for the committers.
>>
>>> The argument for alternative designs of the API is great too because it
>>> allows people to comment on the API design as they use it.
>> There are too many possibilities; that's why design change is usually
>> driven by new usage (user input) or discovering internal inconsistencies
>> (developer input).
>> Personally, I'm also open to a complete rewrite of some functionality,
>> but those who propose it must be ready to perform a _committer_ work
>> (namely, be around in order to maintain what they have asked to be
>> included in CM).
>>
>>
>> Gilles
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message