commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Commons Math (r)evolution
Date Thu, 09 Jun 2016 22:56:10 GMT
On Thu, 9 Jun 2016 14:53:20 -0700, Ralph Goers wrote:
>> On Jun 9, 2016, at 2:12 PM, Gilles <gilles@harfang.homelinux.org> 
>> wrote:
>>
>> Hello Jörg.
>>
>> On Thu, 09 Jun 2016 09:43:06 +0200, Jörg Schaible wrote:
>>> Hi Gilles,
>>>
>>> Gilles wrote:
>>>
>>>> Hi.
>>>>
>>>> On Wed, 8 Jun 2016 23:50:00 +0300, Artem Barger wrote:
>>>>> On Wed, Jun 8, 2016 at 12:25 AM, Gilles
>>>>> <gilles@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> According to JIRA, among 180 issues currently targeted for the
>>>>>>>> next major release (v4.0), 139 have been resolved (75 of
which
>>>>>>>> were not in v3.6.1).
>>>>>>>>
>>>>>>>>
>>>>>>> ​Huh, it's above of 75% completion :)​
>>>>>>>
>>>>>>
>>>>>> Everybody is welcome to review the "open" issues and comment
>>>>>> about them.
>>>>>>
>>>>>>
>>>>> ​I guess someone need to prioritize them​ according to they
>>>>> importance for
>>>>> release.
>>>>
>>>> Importance is relative... :-}
>>>>
>>>> IMO, it is important to not release unsupported code.
>>>
>>> Unit test *are* kind of support.
>>
>> Unit tests are not what I mean by "support".  They only increase the
>> probability that the code behaves as expected. [And sometimes they 
>> do
>> not because they can be buggy too, as I discovered when refactoring
>> the "random" package.]
>
> Now that is a funny argument.  If you can write a proper unit test
> for the code typically you understand what the code is doing and 
> could
> fix it if needed.

Yes.  Where did I say otherwise?

>>
>> But anyways, my reservations have nothing to do with the 
>> functionality
>> of released code: users who are satisfied with the service provided 
>> by
>> v3.6.1 (or any of the previous versions of CM) have no reason to 
>> upgrade
>> to 4.0.  [By upgrading, all they get is the obligation to change the
>> "import" statements.]
>>
>> And we have no reason to release a v4.0 of a code that
>> 1. has not changed
>> 2. is not supported
>
> What you seem to be proposing is tossing code that “isn’t supported”
> even if it works just fine. I don’t understand why you would want to
> do that.

No, you misunderstood: I want to work on, and release, code which we
can support.
Code which we can't support will stay in the "develop" branch until
someone feels confident to release it.

> What I am seeing here is a bunch of people coming on board who seem
> to really want to help and get involved. Before doing radical things
> like dumping a large portion of the code base please take the time to
> see how things play out.

I did take the time (and I'm not going to continue wasting my time the
way I did all these years).

I just gave two examples of unsolvable issues due to code being
unsupported.  Please let us know how you'd handle them.

Also, to conclude a discussion that go in circles: I'm not preventing
(how could I?) you to release CM v4.0 with whatever contents you see
fit.
I gave my arguments for discouraging such a step and others in favour
of my preferred alternative, which I'd like to start working on,
concretely, in order to see how it'll play out indeed.

Gilles

> Ralph


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message