commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
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 <> 
>> 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
>>>>> <>
>>>>> wrote:
>>>>>> According to JIRA, among 180 issues currently targeted for the
>>>>>>>> next major release (v4.0), 139 have been resolved (75 of
>>>>>>>> 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
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.


> Ralph

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

View raw message