Re: [Math] Changes on the 3.x line

2016-10-13 Thread Gilles 

On Thu, 13 Oct 2016 14:51:05 -0700, Ralph Goers wrote:
On Oct 13, 2016, at 10:50 AM, Gilles  
wrote:


On Thu, 13 Oct 2016 10:18:36 -0700, Gary Gregory wrote:
On Thu, Oct 13, 2016 at 9:13 AM, Ralph Goers 


wrote:



> On Oct 12, 2016, at 4:10 PM, Gilles 


wrote:
>
> IIRC, many PMC members did not "like" the idea of having more
> components.
> Even less so if those components are being extracted from 
Commons

> Math.
> The least "problematic" one, Commons RNG, barely collected the
> number of required votes for a release.
>
> Has that changed?
> Shall we request git repositories for the candidate components
> which I suggested back in May?


To be clear, Apache Commons currently lists about 40 sub-projects. 
These
projects are typically small and not closely related with any 
other

sub-project in any clear way.  The objection isn’t to adding more
sub-projects, it is to adding more sub-projects that seem related 
closely
enough that really belong together.  However, I don’t believe 
anyone

objected to Commons Math being a multi-module project.

I would object to creating new Commons components that are forked 
off from

Commons Math that have no maintainers.


It is "Commons Math" that does not have maintainers.

The new components, would, conspicuously, have maintainers.
That's one of the main arguments in favour of this option.


If there is code the Commons Math
team doesn’t want then just get rid of it in your new version.


This option had been rejected in previous discussions, when I
suggested that I would not release code that I could not
maintain.



Replace “I” with “we” and we are in agreement. It really isn’t all
that important what one individual can or cannot do.


I don't follow those statements at all.

*I* cannot speak for others; all I can say for sure is that *I*
would not release the whole of CM (be it 3 or 4) knowing full
well that there are whole swaths of code which nobody here can
maintain.[1]

And it seems that nobody else will do it either.

Hence, what is interesting to know is if you (each PMC member)
trust another PMC member (me) that says that the new components
would be maintained.

I also wrote several times why I think so.  [Where the opposite
argument ("CM is maintainable") is still false after 10 months
have elapsed.]

Quoting Jörg in an earlier post in this thread:
  "And most of us will agree that CM4 is dead."
[This is actually the first time it is acknowledged by someone
other than me.]

So the question is quite simple, synthetic and direct: Why
still oppose the creation of new components?


Gilles

[1] Because *I* consider it dishonest towards the potential
users. [We had a telling example with a requested
enhancement to the ODE functionality a few months ago.
Even in parts which I thought could still be maintained,
bugs turned out that are not easy to fix.]



Ralph



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

Re: [Math] Changes on the 3.x line

2016-10-13 Thread Ralph Goers 

> On Oct 13, 2016, at 10:50 AM, Gilles  wrote:
> 
> On Thu, 13 Oct 2016 10:18:36 -0700, Gary Gregory wrote:
>> On Thu, Oct 13, 2016 at 9:13 AM, Ralph Goers 
>> wrote:
>> 
>>> 
>>> > On Oct 12, 2016, at 4:10 PM, Gilles 
>>> wrote:
>>> >
>>> > IIRC, many PMC members did not "like" the idea of having more
>>> > components.
>>> > Even less so if those components are being extracted from Commons
>>> > Math.
>>> > The least "problematic" one, Commons RNG, barely collected the
>>> > number of required votes for a release.
>>> >
>>> > Has that changed?
>>> > Shall we request git repositories for the candidate components
>>> > which I suggested back in May?
>>> 
>>> 
>>> To be clear, Apache Commons currently lists about 40 sub-projects. These
>>> projects are typically small and not closely related with any other
>>> sub-project in any clear way.  The objection isn’t to adding more
>>> sub-projects, it is to adding more sub-projects that seem related closely
>>> enough that really belong together.  However, I don’t believe anyone
>>> objected to Commons Math being a multi-module project.
>>> 
>>> I would object to creating new Commons components that are forked off from
>>> Commons Math that have no maintainers.
> 
> It is "Commons Math" that does not have maintainers.
> 
> The new components, would, conspicuously, have maintainers.
> That's one of the main arguments in favour of this option.
> 
>>> If there is code the Commons Math
>>> team doesn’t want then just get rid of it in your new version.
> 
> This option had been rejected in previous discussions, when I
> suggested that I would not release code that I could not
> maintain.
> 

Replace “I” with “we” and we are in agreement. It really isn’t all that 
important what one individual can or cannot do.

Ralph

Re: [Math] Changes on the 3.x line

2016-10-13 Thread Gilles 

On Thu, 13 Oct 2016 10:18:36 -0700, Gary Gregory wrote:
On Thu, Oct 13, 2016 at 9:13 AM, Ralph Goers 


wrote:



> On Oct 12, 2016, at 4:10 PM, Gilles 
wrote:
>
> IIRC, many PMC members did not "like" the idea of having more
> components.
> Even less so if those components are being extracted from Commons
> Math.
> The least "problematic" one, Commons RNG, barely collected the
> number of required votes for a release.
>
> Has that changed?
> Shall we request git repositories for the candidate components
> which I suggested back in May?


To be clear, Apache Commons currently lists about 40 sub-projects. 
These

projects are typically small and not closely related with any other
sub-project in any clear way.  The objection isn’t to adding more
sub-projects, it is to adding more sub-projects that seem related 
closely

enough that really belong together.  However, I don’t believe anyone
objected to Commons Math being a multi-module project.

I would object to creating new Commons components that are forked 
off from

Commons Math that have no maintainers.


It is "Commons Math" that does not have maintainers.

The new components, would, conspicuously, have maintainers.
That's one of the main arguments in favour of this option.


If there is code the Commons Math
team doesn’t want then just get rid of it in your new version.


This option had been rejected in previous discussions, when I
suggested that I would not release code that I could not
maintain.


Gilles



+1

Gary



Ralph





--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition





JUnit in Action, Second Edition





Spring Batch in Action




Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory



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

Re: [Math] Changes on the 3.x line

2016-10-13 Thread Gary Gregory 
On Thu, Oct 13, 2016 at 9:13 AM, Ralph Goers 
wrote:

>
> > On Oct 12, 2016, at 4:10 PM, Gilles 
> wrote:
> >
> > IIRC, many PMC members did not "like" the idea of having more
> > components.
> > Even less so if those components are being extracted from Commons
> > Math.
> > The least "problematic" one, Commons RNG, barely collected the
> > number of required votes for a release.
> >
> > Has that changed?
> > Shall we request git repositories for the candidate components
> > which I suggested back in May?
>
>
> To be clear, Apache Commons currently lists about 40 sub-projects. These
> projects are typically small and not closely related with any other
> sub-project in any clear way.  The objection isn’t to adding more
> sub-projects, it is to adding more sub-projects that seem related closely
> enough that really belong together.  However, I don’t believe anyone
> objected to Commons Math being a multi-module project.
>
> I would object to creating new Commons components that are forked off from
> Commons Math that have no maintainers. If there is code the Commons Math
> team doesn’t want then just get rid of it in your new version.
>

+1

Gary

>
> Ralph




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Changes on the 3.x line

2016-10-13 Thread Gary Gregory 
On Thu, Oct 13, 2016 at 1:15 AM, Gilles 
wrote:

> On Wed, 12 Oct 2016 19:37:20 -0700, Gary Gregory wrote:
>
>> On Oct 12, 2016 4:17 PM, "Gilles"  wrote:
>>
>>>
>>> On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote:
>>>

 On Oct 12, 2016 3:34 PM, "Gilles"  wrote:

>
>
> On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:
>
>>
>>
>> Le 12/10/2016 à 18:45, Gilles a écrit :
>>
>> So, what you say in substance is that you'd rather _wait_ for
>>> someone to come by who will want to work with you on 3.x, rather
>>> than continue with people, here and now, a work (CM4) that
>>> started more than 3 years ago.
>>>
>>
>>
>>
>> To be clear, I have no plan to maintain CM 3. I applied a small bug
>> fix
>> to CM 4, I just thought it would be nice to backport it if ever a new
>>
> CM
>>
>>> 3 release is required. That's all.
>>
>
>
>
> That backport served as an example that could lead to a broader
> reflection on the future of a project and the "community" around
> it; but you ignored it, again, by expressly cutting that part of
> my message.
>
>
> I'm doing open source mostly for fun, my motivation is to help and make
>> something useful to others, and if a fixed CM 3 makes someone happy,
>> then so am I.
>>
>
>
>
> I am sad that those one-shots gives the false impression that
> CM3 (or CM4) is alive.
>
> Some people here could have the project to maintain CM3; even
> if I'd prefer that they would work on CM4, they are of course
> free to decide where they want to contribute.
>
> However, I find it extremely uneasy that there is no roadmap
> whatsoever; only criticism of what I proposed.
>
> Is that fix worth a CM 3.7 release?
> If not, and nobody works towards a release, what did the
> reporter actually gain?
>


 Sometimes, a user just wants a bug fix in an easy to apply release. The
 liveliness of the project switches state as soon as the fix is
 delivered.
 Release notes can warn that new features are only happening on the
 master
 branch. If I get a bug fix I am happy ;-)

>>>
>>>
>>> This is all fine, in "theory". But:
>>>  * Who is going to _make_ a release for each applied patch?
>>>
>>
>> Speaking here only about 3.x...
>>
>> Whomever feels like it! :-) We do not have ownership as you well know. I
>> do
>> not have a need for a patch today and I do not foresee needing one, but I
>> would certainly not be shy about cutting an RC if I needed one.
>>
>
> Even if he wished to do it, the reporter and patch provider could
> not do it (unless he is a committer already).
>
> Will you grant the privilege on the basis of one patch?


I should have been clearer, sorry. I meant to say that it is up to a
Commons committer (which means an Apache Committer really) to step up and
do the release. The PMC still gets to VOTE of course, so it makes sense to
discuss fixes and releases on the ML to see what would put -1's in the path
of a release once an RM steps forward, this is no different than another
component.



>
>
>  * Why this fix and not the other ones reported on JIRA?
>>>
>>
>> It's up to the volunteer that steps up, with reasonable feedback from this
>> peanut gallery :-)
>>
>
> PMC members do not ask for feedback.
> They do as they wish.
> Usually, that's fine.
> But in the case of a project that is in a bad situation like
> CM (I call "bad", the shift from "bug report is handled within
> hours" to "unmaintained"), it's not.
>
>  * If a release should be considered only after all reported
>>>issues have been examined, who is going to do that work?
>>>
>>
>> See above.
>>
>
> Well, the above is a non-answer.
>
> No "privileged" developer is likely to spend his time doing
> point releases.
>

What's a "privileged" developer? In the past I've cur releases for selfish
needs: I need it at work or for a personal project. I've also cut them just
because it bugs me to see fixes pending in changes.xml and no reason not to
push them out. It's also a matter of time.

Gary

So there should be a roadmap such as "new point release every
> 6 months, containing whatever has been fixed".
>
> Otherwise, why would a contributor be motivated to provide a
> patch?
>
>
>>> Where is the roadmap?
>>>
>>
>> We do not need a roadmap for 3.x fixes IMO.
>>
>
> I do not agree; I gave the reason above.
>
> For 4.x, the answer is the same as it has always been, we discuss on the
>> ML. How else would it happen? At an Apache conference or meetup I
>> suppose...
>>
>
> I've discussed a lot on the ML.
> I've proposed things, and there has been no alternative (I do not
> call letting the code rot, an alternative).
>
> Don't you think that having maintained CM alone during 6 months
> (from December to May) and, my stopping doing that have resulted
> in nobody else doing it, is enough p

Re: [Math] Changes on the 3.x line

2016-10-13 Thread Ralph Goers 

> On Oct 12, 2016, at 4:10 PM, Gilles  wrote:
> 
> IIRC, many PMC members did not "like" the idea of having more
> components.
> Even less so if those components are being extracted from Commons
> Math.
> The least "problematic" one, Commons RNG, barely collected the
> number of required votes for a release.
> 
> Has that changed?
> Shall we request git repositories for the candidate components
> which I suggested back in May?


To be clear, Apache Commons currently lists about 40 sub-projects. These 
projects are typically small and not closely related with any other sub-project 
in any clear way.  The objection isn’t to adding more sub-projects, it is to 
adding more sub-projects that seem related closely enough that really belong 
together.  However, I don’t believe anyone objected to Commons Math being a 
multi-module project.

I would object to creating new Commons components that are forked off from 
Commons Math that have no maintainers. If there is code the Commons Math team 
doesn’t want then just get rid of it in your new version.

Ralph

Re: [Math] Changes on the 3.x line

2016-10-13 Thread Gilles 

On Wed, 12 Oct 2016 19:37:20 -0700, Gary Gregory wrote:
On Oct 12, 2016 4:17 PM, "Gilles"  
wrote:


On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote:


On Oct 12, 2016 3:34 PM, "Gilles"  
wrote:



On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:



Le 12/10/2016 à 18:45, Gilles a écrit :


So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.




To be clear, I have no plan to maintain CM 3. I applied a small 
bug fix
to CM 4, I just thought it would be nice to backport it if ever a 
new

CM

3 release is required. That's all.




That backport served as an example that could lead to a broader
reflection on the future of a project and the "community" around
it; but you ignored it, again, by expressly cutting that part of
my message.


I'm doing open source mostly for fun, my motivation is to help 
and make
something useful to others, and if a fixed CM 3 makes someone 
happy,

then so am I.




I am sad that those one-shots gives the false impression that
CM3 (or CM4) is alive.

Some people here could have the project to maintain CM3; even
if I'd prefer that they would work on CM4, they are of course
free to decide where they want to contribute.

However, I find it extremely uneasy that there is no roadmap
whatsoever; only criticism of what I proposed.

Is that fix worth a CM 3.7 release?
If not, and nobody works towards a release, what did the
reporter actually gain?



Sometimes, a user just wants a bug fix in an easy to apply release. 
The
liveliness of the project switches state as soon as the fix is 
delivered.
Release notes can warn that new features are only happening on the 
master

branch. If I get a bug fix I am happy ;-)



This is all fine, in "theory". But:
 * Who is going to _make_ a release for each applied patch?


Speaking here only about 3.x...

Whomever feels like it! :-) We do not have ownership as you well 
know. I do
not have a need for a patch today and I do not foresee needing one, 
but I

would certainly not be shy about cutting an RC if I needed one.


Even if he wished to do it, the reporter and patch provider could
not do it (unless he is a committer already).

Will you grant the privilege on the basis of one patch?


 * Why this fix and not the other ones reported on JIRA?


It's up to the volunteer that steps up, with reasonable feedback from 
this

peanut gallery :-)


PMC members do not ask for feedback.
They do as they wish.
Usually, that's fine.
But in the case of a project that is in a bad situation like
CM (I call "bad", the shift from "bug report is handled within
hours" to "unmaintained"), it's not.


 * If a release should be considered only after all reported
   issues have been examined, who is going to do that work?


See above.


Well, the above is a non-answer.

No "privileged" developer is likely to spend his time doing
point releases.
So there should be a roadmap such as "new point release every
6 months, containing whatever has been fixed".

Otherwise, why would a contributor be motivated to provide a
patch?



Where is the roadmap?


We do not need a roadmap for 3.x fixes IMO.


I do not agree; I gave the reason above.

For 4.x, the answer is the same as it has always been, we discuss on 
the
ML. How else would it happen? At an Apache conference or meetup I 
suppose...


I've discussed a lot on the ML.
I've proposed things, and there has been no alternative (I do not
call letting the code rot, an alternative).

Don't you think that having maintained CM alone during 6 months
(from December to May) and, my stopping doing that have resulted
in nobody else doing it, is enough proof that the development
model is not good for this situation (big code, no team), and
that the "community" and PMC should support a radical change?

If not, it means that fairly soon, people will search for
alternative projects that are well maintained.

People who read this and have a certain competing project in
mind that has this property should say clearly that they in
fact support _that_ alternative.
All PMC members should indicate where they stand.


Gilles



Gary


Gilles




Gary



What is the added value of this project if there is no
decision to move forward?
As I indicated a few months ago, the code sits there; and
the more time passes, the less it will attract new
contributors.


Gilles




Emmanuel Bourg






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

Re: [Math] Changes on the 3.x line

2016-10-13 Thread Gilles 

On Wed, 12 Oct 2016 19:37:20 -0700, Gary Gregory wrote:
On Oct 12, 2016 4:17 PM, "Gilles"  
wrote:


On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote:


On Oct 12, 2016 3:34 PM, "Gilles"  
wrote:



On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:



Le 12/10/2016 à 18:45, Gilles a écrit :


So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.




To be clear, I have no plan to maintain CM 3. I applied a small 
bug fix
to CM 4, I just thought it would be nice to backport it if ever a 
new

CM

3 release is required. That's all.




That backport served as an example that could lead to a broader
reflection on the future of a project and the "community" around
it; but you ignored it, again, by expressly cutting that part of
my message.


I'm doing open source mostly for fun, my motivation is to help 
and make
something useful to others, and if a fixed CM 3 makes someone 
happy,

then so am I.




I am sad that those one-shots gives the false impression that
CM3 (or CM4) is alive.

Some people here could have the project to maintain CM3; even
if I'd prefer that they would work on CM4, they are of course
free to decide where they want to contribute.

However, I find it extremely uneasy that there is no roadmap
whatsoever; only criticism of what I proposed.

Is that fix worth a CM 3.7 release?
If not, and nobody works towards a release, what did the
reporter actually gain?



Sometimes, a user just wants a bug fix in an easy to apply release. 
The
liveliness of the project switches state as soon as the fix is 
delivered.
Release notes can warn that new features are only happening on the 
master

branch. If I get a bug fix I am happy ;-)



This is all fine, in "theory". But:
 * Who is going to _make_ a release for each applied patch?


Speaking here only about 3.x...

Whomever feels like it! :-) We do not have ownership as you well 
know. I do
not have a need for a patch today and I do not foresee needing one, 
but I

would certainly not be shy about cutting an RC if I needed one.


That's


 * Why this fix and not the other ones reported on JIRA?


It's up to the volunteer that steps up, with reasonable feedback from 
this

peanut gallery :-)


 * If a release should be considered only after all reported
   issues have been examined, who is going to do that work?


See above.



Where is the roadmap?


We do not need a roadmap for 3.x fixes IMO.

For 4.x, the answer is the same as it has always been, we discuss on 
the
ML. How else would it happen? At an Apache conference or meetup I 
suppose...


Gary


Gilles




Gary



What is the added value of this project if there is no
decision to move forward?
As I indicated a few months ago, the code sits there; and
the more time passes, the less it will attract new
contributors.


Gilles




Emmanuel Bourg






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

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Gary Gregory 
On Oct 12, 2016 4:17 PM, "Gilles"  wrote:
>
> On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote:
>>
>> On Oct 12, 2016 3:34 PM, "Gilles"  wrote:
>>>
>>>
>>> On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:


 Le 12/10/2016 à 18:45, Gilles a écrit :

> So, what you say in substance is that you'd rather _wait_ for
> someone to come by who will want to work with you on 3.x, rather
> than continue with people, here and now, a work (CM4) that
> started more than 3 years ago.



 To be clear, I have no plan to maintain CM 3. I applied a small bug fix
 to CM 4, I just thought it would be nice to backport it if ever a new
CM
 3 release is required. That's all.
>>>
>>>
>>>
>>> That backport served as an example that could lead to a broader
>>> reflection on the future of a project and the "community" around
>>> it; but you ignored it, again, by expressly cutting that part of
>>> my message.
>>>
>>>
 I'm doing open source mostly for fun, my motivation is to help and make
 something useful to others, and if a fixed CM 3 makes someone happy,
 then so am I.
>>>
>>>
>>>
>>> I am sad that those one-shots gives the false impression that
>>> CM3 (or CM4) is alive.
>>>
>>> Some people here could have the project to maintain CM3; even
>>> if I'd prefer that they would work on CM4, they are of course
>>> free to decide where they want to contribute.
>>>
>>> However, I find it extremely uneasy that there is no roadmap
>>> whatsoever; only criticism of what I proposed.
>>>
>>> Is that fix worth a CM 3.7 release?
>>> If not, and nobody works towards a release, what did the
>>> reporter actually gain?
>>
>>
>> Sometimes, a user just wants a bug fix in an easy to apply release. The
>> liveliness of the project switches state as soon as the fix is delivered.
>> Release notes can warn that new features are only happening on the master
>> branch. If I get a bug fix I am happy ;-)
>
>
> This is all fine, in "theory". But:
>  * Who is going to _make_ a release for each applied patch?

Speaking here only about 3.x...

Whomever feels like it! :-) We do not have ownership as you well know. I do
not have a need for a patch today and I do not foresee needing one, but I
would certainly not be shy about cutting an RC if I needed one.

>  * Why this fix and not the other ones reported on JIRA?

It's up to the volunteer that steps up, with reasonable feedback from this
peanut gallery :-)

>  * If a release should be considered only after all reported
>issues have been examined, who is going to do that work?

See above.

>
> Where is the roadmap?

We do not need a roadmap for 3.x fixes IMO.

For 4.x, the answer is the same as it has always been, we discuss on the
ML. How else would it happen? At an Apache conference or meetup I suppose...

Gary
>
> Gilles
>
>
>>
>> Gary
>>>
>>>
>>> What is the added value of this project if there is no
>>> decision to move forward?
>>> As I indicated a few months ago, the code sits there; and
>>> the more time passes, the less it will attract new
>>> contributors.
>>>
>>>
>>> Gilles
>>>
>>>

 Emmanuel Bourg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Gilles 

On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote:
On Oct 12, 2016 3:34 PM, "Gilles"  
wrote:


On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:


Le 12/10/2016 à 18:45, Gilles a écrit :


So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.



To be clear, I have no plan to maintain CM 3. I applied a small bug 
fix
to CM 4, I just thought it would be nice to backport it if ever a 
new CM

3 release is required. That's all.



That backport served as an example that could lead to a broader
reflection on the future of a project and the "community" around
it; but you ignored it, again, by expressly cutting that part of
my message.


I'm doing open source mostly for fun, my motivation is to help and 
make
something useful to others, and if a fixed CM 3 makes someone 
happy,

then so am I.



I am sad that those one-shots gives the false impression that
CM3 (or CM4) is alive.

Some people here could have the project to maintain CM3; even
if I'd prefer that they would work on CM4, they are of course
free to decide where they want to contribute.

However, I find it extremely uneasy that there is no roadmap
whatsoever; only criticism of what I proposed.

Is that fix worth a CM 3.7 release?
If not, and nobody works towards a release, what did the
reporter actually gain?


Sometimes, a user just wants a bug fix in an easy to apply release. 
The
liveliness of the project switches state as soon as the fix is 
delivered.
Release notes can warn that new features are only happening on the 
master

branch. If I get a bug fix I am happy ;-)


This is all fine, in "theory". But:
 * Who is going to _make_ a release for each applied patch?
 * Why this fix and not the other ones reported on JIRA?
 * If a release should be considered only after all reported
   issues have been examined, who is going to do that work?

Where is the roadmap?

Gilles



Gary


What is the added value of this project if there is no
decision to move forward?
As I indicated a few months ago, the code sits there; and
the more time passes, the less it will attract new
contributors.


Gilles




Emmanuel Bourg



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

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Gilles 

On Wed, 12 Oct 2016 19:18:50 +0200, Jörg Schaible wrote:

Hi Gilles,

Gilles wrote:


On Wed, 12 Oct 2016 16:57:03 +0200, Emmanuel Bourg wrote:

Le 12/10/2016 à 16:15, Gilles a écrit :


The 3.x line is obsolete.
No new feature or bug-fix should be introduced there.


Hi Gilles,

I understand you don't want to invest time in maintaining the 3.x
line
and I respect that, but others might be interested. I don't think
pushing minor bug fixes to CM 3 will undermine CM 4.


Work on 3.X did undermine CM4.

[The problem here is that you want me to be synthetic, but you
seem to have no clue about the history, thereby forcing me to
recollect facts from the past, because you don't believe my
synthetic statement above.]

So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.


No, that's not what Emmanuel said, that's what you have implied. Your 
plan

is still valid to extract parts of the code base into own smaller
components. Once that components are created, we can deprecate the 
extracted
code in the CM3 code base and have a release. That's what we should 
do for

our existing users.


IIRC, many PMC members did not "like" the idea of having more
components.
Even less so if those components are being extracted from Commons
Math.
The least "problematic" one, Commons RNG, barely collected the
number of required votes for a release.

Has that changed?
Shall we request git repositories for the candidate components
which I suggested back in May?

You made it very clear that you have no intention to put any 
additional
effort into CM3. Fine. And most of us will agree that CM4 is dead. 
But that
does not prevent any other committer from maintaining the CM3 line 
i.e.
applying bug fixes or small improvements as long as binary 
compatibility is

ensured.


There is no sufficient manpower to work on both (cf. the backlog
of issues). [There wasn't before, and the situation did not
improve after the fork.]


Obviously some work was done.


It will be a waste for everyone if we split the already scarce
resources to work on the two lines, of which the 3.x line will
always be a "sub-Hipparchus".


Noone wastes *your* time ;-)


Let me assure you that plenty of my time has been wasted.
First and foremost because I continued the maintenance of
CM4 for months.
Then because I had to argue for salvaging some CM4 codes
(rather than simply "do it" as Apache would have it).

Of course, you can say that its my fault, and it is; that
I should not have tried to convince people, and should
have left, like others did.


In some areas/packages, code in the CM4 is still the same as
in 3.x.  And there is no one left in Commons that would want
to significantly modify those areas, for which I have no qualms
if you maintain them in 3.x.

In areas where major changes were introduced in the development
branch, my proposal is still that we try to split them off CM
(see rationale in my posts sent in May).

Commits should be done either in the 3.x line or in master, but
not both.


This depends on the fact what code base you intent to extract for a 
new
component. Fixing code that exists in CM3 as well as in CM4 and that 
is
target for a new component is IMHO completely valid as long as the 
new
component does not yet exist. It is not clear in any case whether 
your

intention is to extract the code from CM3 or CM4,


Sorry, but CM4 is obviously the up-to-date code. See the log.
It would make no sense to "extract" anything from CM3.

[It should be ensured indeed that all fixes are consistently
applied to either the component, or the legacy code.]


but after all it should
contain the bug fix.


Sure.
That's why I asked for a constructive discussion on "legacy code"
(CM3-compatible) vs "new components" (extracted from CM master).


Can we agree on a list of legacy packages (maintained in 3.x),
and a list of actively modified ones (worked on in master, in
view of releasing them as independent tools)?


This list is obvious when all extracted code is marked as deprecated.


A circular argument: Some decision must be made to start working,
and to deprecate codes.

As far as CM code is concerned, PMC members, even those who do
not contribute, should either support the creation of new
components), or propose alternatives (e.g. volunteer to
actively maintain CM3).
An attitude that amounts to block whatever work is being done
(in the way of not voting a release) does not qualify as
"management".

Regards,
Gilles



Cheers,
Jörg





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

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Gary Gregory 
On Oct 12, 2016 3:34 PM, "Gilles"  wrote:
>
> On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:
>>
>> Le 12/10/2016 à 18:45, Gilles a écrit :
>>
>>> So, what you say in substance is that you'd rather _wait_ for
>>> someone to come by who will want to work with you on 3.x, rather
>>> than continue with people, here and now, a work (CM4) that
>>> started more than 3 years ago.
>>
>>
>> To be clear, I have no plan to maintain CM 3. I applied a small bug fix
>> to CM 4, I just thought it would be nice to backport it if ever a new CM
>> 3 release is required. That's all.
>
>
> That backport served as an example that could lead to a broader
> reflection on the future of a project and the "community" around
> it; but you ignored it, again, by expressly cutting that part of
> my message.
>
>
>> I'm doing open source mostly for fun, my motivation is to help and make
>> something useful to others, and if a fixed CM 3 makes someone happy,
>> then so am I.
>
>
> I am sad that those one-shots gives the false impression that
> CM3 (or CM4) is alive.
>
> Some people here could have the project to maintain CM3; even
> if I'd prefer that they would work on CM4, they are of course
> free to decide where they want to contribute.
>
> However, I find it extremely uneasy that there is no roadmap
> whatsoever; only criticism of what I proposed.
>
> Is that fix worth a CM 3.7 release?
> If not, and nobody works towards a release, what did the
> reporter actually gain?

Sometimes, a user just wants a bug fix in an easy to apply release. The
liveliness of the project switches state as soon as the fix is delivered.
Release notes can warn that new features are only happening on the master
branch. If I get a bug fix I am happy ;-)

Gary
>
> What is the added value of this project if there is no
> decision to move forward?
> As I indicated a few months ago, the code sits there; and
> the more time passes, the less it will attract new
> contributors.
>
>
> Gilles
>
>
>>
>> Emmanuel Bourg
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Gilles 

On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:

Le 12/10/2016 à 18:45, Gilles a écrit :


So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.


To be clear, I have no plan to maintain CM 3. I applied a small bug 
fix
to CM 4, I just thought it would be nice to backport it if ever a new 
CM

3 release is required. That's all.


That backport served as an example that could lead to a broader
reflection on the future of a project and the "community" around
it; but you ignored it, again, by expressly cutting that part of
my message.

I'm doing open source mostly for fun, my motivation is to help and 
make

something useful to others, and if a fixed CM 3 makes someone happy,
then so am I.


I am sad that those one-shots gives the false impression that
CM3 (or CM4) is alive.

Some people here could have the project to maintain CM3; even
if I'd prefer that they would work on CM4, they are of course
free to decide where they want to contribute.

However, I find it extremely uneasy that there is no roadmap
whatsoever; only criticism of what I proposed.

Is that fix worth a CM 3.7 release?
If not, and nobody works towards a release, what did the
reporter actually gain?

What is the added value of this project if there is no
decision to move forward?
As I indicated a few months ago, the code sits there; and
the more time passes, the less it will attract new
contributors.


Gilles



Emmanuel Bourg





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

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Emmanuel Bourg 
Le 12/10/2016 à 18:45, Gilles a écrit :

> So, what you say in substance is that you'd rather _wait_ for
> someone to come by who will want to work with you on 3.x, rather
> than continue with people, here and now, a work (CM4) that
> started more than 3 years ago.

To be clear, I have no plan to maintain CM 3. I applied a small bug fix
to CM 4, I just thought it would be nice to backport it if ever a new CM
3 release is required. That's all.

I'm doing open source mostly for fun, my motivation is to help and make
something useful to others, and if a fixed CM 3 makes someone happy,
then so am I.

Emmanuel Bourg


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

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Jörg Schaible 
Hi Gilles,

Gilles wrote:

> On Wed, 12 Oct 2016 16:57:03 +0200, Emmanuel Bourg wrote:
>> Le 12/10/2016 à 16:15, Gilles a écrit :
>>
>>> The 3.x line is obsolete.
>>> No new feature or bug-fix should be introduced there.
>>
>> Hi Gilles,
>>
>> I understand you don't want to invest time in maintaining the 3.x
>> line
>> and I respect that, but others might be interested. I don't think
>> pushing minor bug fixes to CM 3 will undermine CM 4.
> 
> Work on 3.X did undermine CM4.
> 
> [The problem here is that you want me to be synthetic, but you
> seem to have no clue about the history, thereby forcing me to
> recollect facts from the past, because you don't believe my
> synthetic statement above.]
> 
> So, what you say in substance is that you'd rather _wait_ for
> someone to come by who will want to work with you on 3.x, rather
> than continue with people, here and now, a work (CM4) that
> started more than 3 years ago.

No, that's not what Emmanuel said, that's what you have implied. Your plan 
is still valid to extract parts of the code base into own smaller 
components. Once that components are created, we can deprecate the extracted 
code in the CM3 code base and have a release. That's what we should do for 
our existing users.

You made it very clear that you have no intention to put any additional 
effort into CM3. Fine. And most of us will agree that CM4 is dead. But that 
does not prevent any other committer from maintaining the CM3 line i.e. 
applying bug fixes or small improvements as long as binary compatibility is 
ensured.

> There is no sufficient manpower to work on both (cf. the backlog
> of issues). [There wasn't before, and the situation did not
> improve after the fork.]

Obviously some work was done.

> It will be a waste for everyone if we split the already scarce
> resources to work on the two lines, of which the 3.x line will
> always be a "sub-Hipparchus".

Noone wastes *your* time ;-)

> In some areas/packages, code in the CM4 is still the same as
> in 3.x.  And there is no one left in Commons that would want
> to significantly modify those areas, for which I have no qualms
> if you maintain them in 3.x.
> 
> In areas where major changes were introduced in the development
> branch, my proposal is still that we try to split them off CM
> (see rationale in my posts sent in May).
> 
> Commits should be done either in the 3.x line or in master, but
> not both.

This depends on the fact what code base you intent to extract for a new 
component. Fixing code that exists in CM3 as well as in CM4 and that is 
target for a new component is IMHO completely valid as long as the new 
component does not yet exist. It is not clear in any case whether your 
intention is to extract the code from CM3 or CM4, but after all it should 
contain the bug fix.

> Can we agree on a list of legacy packages (maintained in 3.x),
> and a list of actively modified ones (worked on in master, in
> view of releasing them as independent tools)?

This list is obvious when all extracted code is marked as deprecated.

Cheers,
Jörg


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

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Gilles 

On Wed, 12 Oct 2016 11:26:23 -0400, Rob Tompkins wrote:
On Oct 12, 2016, at 10:57 AM, Emmanuel Bourg  
wrote:



Le 12/10/2016 à 16:15, Gilles a écrit :

The 3.x line is obsolete.
No new feature or bug-fix should be introduced there.


Hi Gilles,

I understand you don't want to invest time in maintaining the 3.x 
line

and I respect that, but others might be interested. I don't think
pushing minor bug fixes to CM 3 will undermine CM 4.


Being fairly new here, I'm not familiar with how end-of-life'ing a
major version of a component works, but I would think that we would
want to have the next major version out and working before closing 
the

door on the 3.X work.


Because of the lack of resources, the consensus, for the last 10 years,
has been that only one version was supported (the last one).

Each time work was started on a new major version, only bug-fix
releases were done on the supposedly "soon-to-be-deprecated" code.

[Of course, this all broke down when people stopped working on CM4
without public discussions about a new consensus.]


Gilles



-Rob


Emmanuel Bourg




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

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Gilles 

On Wed, 12 Oct 2016 16:57:03 +0200, Emmanuel Bourg wrote:

Le 12/10/2016 à 16:15, Gilles a écrit :


The 3.x line is obsolete.
No new feature or bug-fix should be introduced there.


Hi Gilles,

I understand you don't want to invest time in maintaining the 3.x 
line

and I respect that, but others might be interested. I don't think
pushing minor bug fixes to CM 3 will undermine CM 4.


Work on 3.X did undermine CM4.

[The problem here is that you want me to be synthetic, but you
seem to have no clue about the history, thereby forcing me to
recollect facts from the past, because you don't believe my
synthetic statement above.]

So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.

There is no sufficient manpower to work on both (cf. the backlog
of issues). [There wasn't before, and the situation did not
improve after the fork.]

It will be a waste for everyone if we split the already scarce
resources to work on the two lines, of which the 3.x line will
always be a "sub-Hipparchus".

In some areas/packages, code in the CM4 is still the same as
in 3.x.  And there is no one left in Commons that would want
to significantly modify those areas, for which I have no qualms
if you maintain them in 3.x.

In areas where major changes were introduced in the development
branch, my proposal is still that we try to split them off CM
(see rationale in my posts sent in May).

Commits should be done either in the 3.x line or in master, but
not both.

Can we agree on a list of legacy packages (maintained in 3.x),
and a list of actively modified ones (worked on in master, in
view of releasing them as independent tools)?

Gilles


Emmanuel Bourg




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

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Rob Tompkins 


> On Oct 12, 2016, at 10:57 AM, Emmanuel Bourg  wrote:
> 
>> Le 12/10/2016 à 16:15, Gilles a écrit :
>> 
>> The 3.x line is obsolete.
>> No new feature or bug-fix should be introduced there.
> 
> Hi Gilles,
> 
> I understand you don't want to invest time in maintaining the 3.x line
> and I respect that, but others might be interested. I don't think
> pushing minor bug fixes to CM 3 will undermine CM 4.

Being fairly new here, I'm not familiar with how end-of-life'ing a major 
version of a component works, but I would think that we would want to have the 
next major version out and working before closing the door on the 3.X work. 

-Rob

> Emmanuel Bourg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: [Math] Changes on the 3.x line

2016-10-12 Thread Emmanuel Bourg 
Le 12/10/2016 à 16:15, Gilles a écrit :

> The 3.x line is obsolete.
> No new feature or bug-fix should be introduced there.

Hi Gilles,

I understand you don't want to invest time in maintaining the 3.x line
and I respect that, but others might be interested. I don't think
pushing minor bug fixes to CM 3 will undermine CM 4.

Emmanuel Bourg


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