commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Getting things done
Date Thu, 23 Jun 2016 16:02:48 GMT

On Thu, 23 Jun 2016 14:33:05 +0200, Jochen Wiedmann wrote:
> Hi,
> I'd like an attempt to put an end to all those discussions regarding
> Commons Math (CM). That means, in particular, that we find an common
> agreement on a course of action. So, here's a suggestion (might as
> well call it an offer, because acceptance would mean a lot of work on
> my side)
>   1.) I'll write a proposal to move CM to the Incubator.
>   2.) We'll wait for the Incubators decision. If the Incubator 
> accepts CM.
>   3.) If the Incubator rejects CM, then I'd start another formal TLP 
> vote.
>   4.) If the board accepts the TLP: Very well.
>   5.) If not: So what. Now we know, at least.
> In either case: At the end of the procedure, we'd have clarity. This
> will allow us to focus on a smaller set of issues (technical), and we
> can go on.
> The important part, to me, is to find something on which we can 
> agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.

Thanks for a constructive proposal.

But as you indicated, this means a lot of administrative work whose
ultimate result is far from being certain.
In particular, people have quite clearly pointed out that the incubator
  * is a place for community building
  * not a place to rethink a code base
while we have
  * a community (small perhaps, but sufficient for the code we want to
    release and are able to support), but
  * no viable (IMO) project for salvaging the currently "unsupported"

If Commons reject its own code (IOW does not accept a new component,
despite its potential usefulness, as noted by Eric), then the next
alternative would be a TLP proposal (as attempted by James).  Because
in the TLP, we'll be allowed to release components according to their
individual level of support (which means that well-tested code can be
released ASAP while in the incubator path, it might never be).
Obviously, this would necessitates that the Commons PMC accepts to let
go of the Commons Math code base without any strings attached.

So... I agree with Dave. ;-)

And partially with Emmanuel.

Indeed, it will be much more productive to let the new(bie) team
experiment within Commons by creating the following new components:
  * Commons RNG
  * Commons AltMath
  * Commons MathTools

The first one, pretty much, was accepted. Amazing.

The second one is more fuzzy for some people, but I'll have to stress
again that it's probably because they should have a look at the code!
It will be a zero dependency component (which I had referred to as
"Standard math functions" in the vote thread) with common 
useful beyond "math-centric" (whatever that means) applications.

The last one is a smaller "Commons Math", i.e. stripped of 
unsupported at the time of release.
It is _also_ a new component to clearly separate it from Commons Math,
so that users have an upgrade path; or at least, they will be able to
easily figure out what has become unsupported.
If new contributors come in order to fill the gap, more codes can be
transferred to "MathTools".[2]
[At the same time "Commons Math" itself stays clean of packages
reordering, renaming or removal, so that if and when someone wants to
restart from there, it's trivial.]

I see this proposal as a compromise, deferring(!) further splits of
complex and rational" numbers functionality, while allowing to have a
taste of the the advantages and drawbacks of full modularization (i.e.
individual components).

We do this; if the result suits the PMC, we go on; if not: "Now we 
at least."

Do you agree?
If not, please let us know why.


[1] To become a valuable project, the proposal probably needs a "back 
     basics" study (as noted by Dimitri) in order to generate a 
     initiative, and not just another fork encumbered with all the
     liabilities of the past and no experts to compensate for them.
[2] Of course, the naming is illustrative, subject to a VOTE. ;-)

> Thanks,
> Jochen

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

View raw message