Hello.
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"
code.[1]
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
functionality,
useful beyond "math-centric" (whatever that means) applications.
The last one is a smaller "Commons Math", i.e. stripped of
functionality
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
know,
at least."
Do you agree?
If not, please let us know why.
Regards,
Gilles
[1] To become a valuable project, the proposal probably needs a "back
to
basics" study (as noted by Dimitri) in order to generate a
consistent
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
