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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
