Hello Jared.
I have only contributed a few patches, and I see that there is
argument about whether this thread should even be about anything
other
than technical issues, but I figured I would at least chime in.
I found the submission process to be more difficult than I expected,
but I also think the code turned out better because of it. I was
actually pretty impressed and surprised at the level of scrutiny and
quickness of responses, and it gives me a better feeling about using
the library as a user. If my patches were outright rejected, though,
I might feel differently. I don't know the history of Ajo's issue or
his code, so I can't comment about it specifically.
There was no outright rejection. Along the discussion about the issue,
the features, and the code, I tried to explain several ways that can
speed up the adoption of a contribution; among many other suggestions,
I mentioned my interaction with you.[1]
I really hoped that this example would get us back on track by having
Ajo see how this process can be iterative and lead to a successful
contribution even if the code does not initially meet some quality
requirements.[2]
My strong impression is that the source of the problem is the
misconception that Commons Math is repository of all sorts of
mathematical routines, and that the only requirement is that a
patch submitted by a would-be contributor should be outright
accepted as soon as it solves something for someone.
Indeed:
1. The proposal for implementing improper integrals was welcome.
2. The proposal for implementing additional adaptive algorithms
was welcome.
If he wanted to contribute to Commons Math (and not just "throw
a patch over the wall", as Phil put it), Ajo could have started
from there, and actually work out the details of how to best
integrate the new features into the existing code. Just as you
did.
Regards,
Gilles
[1] http://markmail.org/message/erqohcragbxmm4xa
[2] I explained the reasons for not accepting the patch as it was.
It's all on the ML and yet another installment will not provide
more light.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
