[MATH] what a commons-TLP split could look like

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [MATH] what a commons-TLP split could look like

Gilles Sadowski
On Tue, 21 Jun 2016 11:30:13 -0400, Rob Tompkins wrote:

>> On Jun 21, 2016, at 11:10 AM, Gilles <[hidden email]>
>> wrote:
>>
>> Hello.
>>
>> On Tue, 21 Jun 2016 09:58:40 +0200, Jörg Schaible wrote:
>>> Hi Jochen,
>>>
>>> Jochen Wiedmann wrote:
>>>
>>>> On Tue, Jun 21, 2016 at 9:12 AM, Jörg Schaible
>>>> <[hidden email]> wrote:
>>>>
>>>>> That depends. If some packages of the current CM should stay as
>>>>> own
>>>>> component in Commons, these packages have to be identified.
>>>>
>>>> Whoever would support such a lunacy? Either CM moves entirely, or
>>>> not at
>>>> all.
>>
>> It's not that clear-cut.
>> Thank you (and James, and Niall) for keeping the ball moving, at a
>> point where I was thinking that the game was over.  However, we
>> should
>> all realize that it's not because that all those codes were
>> developed
>> within a single repository that they all belong together.
>>
>> [We got into this dire situation because so much code _depended_
>> (however
>> people here want to put it differently) on one or two people.
>> And it's not a size problem, per se; it's that it covers a very
>> broad
>> scope, requiring expertise levels that are rarely found in one
>> person,
>> even less so in a person who'd dedicated (him)herself to maintaining
>> a
>> Java library.  A TLP is something to attempt but I'm not optimistic
>> that
>> we'll get much more traction.]
>>
>> By having some of the functionality severed from CM, it _increases_
>> the
>> likelihood that it will be used and contributed to.
>> And if this functionality is actually "mature", then it won't have
>> to
>> be (fakely) upgraded (through changing of package name) just because
>> some other (non-mature) code would need it (to allow breaking
>> changes).
>>
>> By way of consequence, such "split off" code will fulfill the
>> Commons'
>> promise of stability.
>>
>> In turn, the separation will have positive effects on the
>> prospective
>> TLP, if just by not having to deal with issues thus become
>> "out-of-scope".
>> There may well be interactions between the TLP and Commons whenever
>> the
>> TLP would choose to depend on a Commons component, but there will be
>> clear API boundaries.
>>
>>> If the new Commons Components have been identified, we can have a
>>> vote. Then
>>> we'll see what the majority want. All I can say now is that we have
>>> currenty
>>> no consensus about anything. Some of the stuff in CM is certainly
>>> common
>>> enough to build a valid Commons component.
>>
>> At last, we agree on this!  [That was my main point since day one
>> (June 5).]
>>
>> Instead of readily discussing the consequence of that observation,
>> we fought
>> about "micro-management" of Commons Math... :-(
>>
>> I'll start a VOTE thread for each new Commons component candidate.
>
> Would it make sense here to simply leave commons-math named commons
> math (mainly because mathematical naming conventions differ from the
> conventional vernacular [e.g. an artifact named commons-analysis
> might
> be confusing]), and deprecate anything that we plan to take and move
> to the incubator/TLP?

Deprecating something makes sense only if we intend to release CM 4.0,
which I'm against, since it would give users the false impression that
they should upgrade, while in fact they should switch to the new
TLP/new
Commons components releases.
An alternative would be to release a v3.6.2 with the "@Deprecated"
annotations (and no other changes).  But I don't know that it is a
common practice to tell users to upgrade just so they can see the
deprecation messages (and do nothing about it since the replacement is
in another library).

You are quite right about a name like "commons-analysis" (but see my
other message; hence that issue probably won't materialize).
For the components which I'll submit to the vote, we'll be able to
easily find unambiguous names.

Regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12