commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: Need for an alternatives to the main line of code.
Date Wed, 21 Aug 2013 21:47:06 GMT
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 

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message