commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@gmail.com>
Subject Re: [MATH]: Current state of project?
Date Fri, 05 Aug 2016 11:47:54 GMT
My overall impression about the problem is that we have a commons component that requires a
considerable of non-java domain specific knowledge to make contributions. Thus, our general
java expertise is not necessarily sufficient to vet contributions. From what I can tell, commons-math
might be the component that is most off the beaten path of the deep java generalist in commons.


So based upon all of the conversation here, I’ve concluded that the best path forward is
to attempt to grow the community inside commons. That’s why I’m sticking with attempts
to make contributions elsewhere in commons to gain the requisite rapport for committer status.
Once I’ve accomplished that, then we’ll have two sets of hands to help here.

Further it seems that we’ve gotten ourselves into a vicious cycle sort of place, in that
to gain a community we need a mechanism to quickly get commits into the component, but to
do that we need more devoted committers (i.e. a larger community).

Any thoughts here?

-Rob

P.S.  Generally, how high is the bar for gaining committer status? I’ve got 2 patches into
math currently and am working on a PR for Lang.

> On Aug 4, 2016, at 8:14 PM, Gilles <gilles@harfang.homelinux.org> wrote:
> 
> On Thu, 4 Aug 2016 13:09:21 -0700, Ralph Goers wrote:
>> Are you waiting on an answer before reviewing and/or merging his pull
>> requests?
> 
> We are all unlucky that CM developers left.  My post with subject
> "Commons Math (r)evolution" (referred to below) dates from June 5
> (in part inspired by Artem's willingness to contribute), and I'm
> still waiting for a "confidence vote" that would reflect what I
> did during the previous 6 months (and my presence here for much
> longer).
> 
> For the record:
> * MATH-1372 has code committed in a dedicated branch.
> * Artem's other issues are with algorithms on which he knows much
>  more than I do.
> * Since then, other requests are pending (also on code which I did
>  not write).
> * Before then, some seemingly serious issues (see "MullerSolver")
>  led to a discussion that was left dangling, indefinitely waiting
>  for an answer (from the people who were busy "privately discussing"
>  their fork).
> 
> Overall, this requires more work than I can reasonably afford.
> I was left the dark during months by the forkers, all the while
> obliviously (and quite unreasonably) doing development for CM v4.0,
> ensuring a presence for CM-related questions and requests on the ML
> and providing timely answers on JIRA (and subsequent commits,
> whenever possible).
> 
> This activity might have led PMC members to believe that it could
> go on forever.
> But the "takeaway" point I had made on June 5 is that "business as
> usual" was not an option (for me). [Hence the alternative proposed
> in that same post.]
> 
> I hope that is quite clear now.
> 
> Gilles
> 
> 
>> Ralph
>> 
>>> On Aug 4, 2016, at 10:49 AM, Gilles <gilles@harfang.homelinux.org> wrote:
>>> 
>>> On Thu, 4 Aug 2016 10:13:26 -0400, Artem Barger wrote:
>>>> On Thu, Aug 4, 2016 at 9:50 AM, Ralph Goers <ralph.goers@dslextreme.com>
>>>> wrote:
>>>> 
>>>>> > All I'm saying this is one of the problems within CM, ​which IMO
only a
>>>>> > symptom for more acute problem of missing community. Also as you
can see
>>>>> in
>>>>> > ML archive I've tried several times to rise discussion around work
I'm
>>>>> > doing and also asked for PR review.
>>>>> > And to be precise, right now the someone to apply is Gilles only,
as far
>>>>> as
>>>>> > I'm getting situation correctly.
>>>>> 
>>>>> Any Commons committer can apply the patch. But to be honest, unless the
>>>>> patch is somewhat obvious or is in a part of the code Gilles isn’t
familiar
>>>>> with, I would expect most everyone would wait for Gilles blessing.
>>>> 
>>>> 
>>>> ​So if almost everyone supposed to wait until Gilles will accept it, why
>>>> Gilles initiatives of how project should be divided into separate
>>>> independent modules could not be accepted? I mean what should happen
>>>> effectively, to move things forward?  I was using CM for implementation of
>>>> different parts of my thesis work and I couldn't imagine to myself that
>>>> proposing improvements or new things related to CM base code will be so
>>>> hard.
>>> 
>>> From reading this thread, it seems that people forgot (or did not
>>> read the whole story from when were informed of the fork) that the
>>> Commons Math team was reduced by more than 85% in a very short time
>>> span. [Without any prior warning or attempt to resolve conflicts
>>> (archives are proofs of that).]
>>> 
>>> I had made a summary of the situation:
>>> http://markmail.org/message/ye6wvqvlvnqe4qrp <http://markmail.org/message/ye6wvqvlvnqe4qrp>
>>> 
>>> After all the discussions, we eventually are back at square one: What
>>> could be done previously with 5 or 6 long-time maintainers (and code
>>> creators), all PMC members, and 2 or 3 additional team members, cannot
>>> be done by me alone.   But PMC people continue to state that I am the
>>> one to do the work (review contributions, "bless" them; from there,
>>> nominate people, "grow a community", and in the mean time, apply all
>>> the patches).
>>> 
>>> If this is indeed the case, then as Artem states pointedly, why can't
>>> I *also* decide what is best for this embryo of a new community of
>>> contributors?
>>> 
>>> Again, nobody answered a simple question:  Why not create as many
>>> components as any PMC member would fancy, and see how they fare in
>>> the world of modules at large, rather than have non-contributors guess
>>> at, or "feel", what is a good component?
>>> 
>>> As I stated many times, this IMO seems a contradiction with the "those
>>> who do the work get to decide" purported Apache/Commons policy...
>>> 
>>> I'm willing to try avoiding what I deems where CM management mistakes.
>>> I refuse to work under the old model.
>>> 
>>> If this PMC refuses to consider the experiment, it should be suggesting
>>> alternatives (e.g. someone else willing to step forward and work under
>>> the old model) or acknowledge that *it* (and not me) prefers to see the
>>> CM code rot.
>>> 
>>> 
>>> Regards,
>>> Gilles
>>> 
>>>> Best regards,
>>>>                     Artem Barger.
>>> 
>>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message