[Math] Expiry date for old issues

[Gilles <gi...@harfang.homelinux.org>]

Hi.

Browsing through the project's open issues is becoming a huge time 
sink.
Commons Math is crumbling under its own weight in this area too.

Some of the old issues are feature requests that are unlikely to be
implemented in the near future.
Others contain discussions and/or patches not updated in years, and are
thus likely outdated wrt to the current line of development.  Just
checking whether anything can be salvaged would anyways take a lot of
time which nobody is prepared to do, as anyone can see from the recent
activity in the project.

Some reports should have been resolved/closed long ago but were not,
probably because of the sheer number of pages to look at.

Lacking resources to manage this large number of issues, I think that
we have to set an expiry date on the JIRA reports (and close them upon
expiry), unless they pertain to confirmed bugs.

There could perhaps be a single open JIRA report with links to all
issues resolved as "Unresolved", just in case some future contributor
wants to revisit whatever had been raised in the past but could not be
completed.

What do you think?

Gilles


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

Re: [Math] Expiry date for old issues

[Gilles <gi...@harfang.homelinux.org>]

Hi.

On Sat, 23 Apr 2016 13:10:57 -0400, Rob Tompkins wrote:
> I would think something along the lines of: if an issues has not been
> apparently worked or or clearly commented on in some number of 
> release
> cycles (maybe 2 or 3), then the issue should be able to be closed.
>
>> On Apr 23, 2016, at 6:26 AM, Gilles <gi...@harfang.homelinux.org> 
>> wrote:
>>
>> Hi.
>>
>> Browsing through the project's open issues is becoming a huge time 
>> sink.
>> Commons Math is crumbling under its own weight in this area too.
>>
>> Some of the old issues are feature requests that are unlikely to be
>> implemented in the near future.
>> Others contain discussions and/or patches not updated in years, and 
>> are
>> thus likely outdated wrt to the current line of development.  Just
>> checking whether anything can be salvaged would anyways take a lot 
>> of
>> time which nobody is prepared to do, as anyone can see from the 
>> recent
>> activity in the project.
>>
>> Some reports should have been resolved/closed long ago but were not,
>> probably because of the sheer number of pages to look at.
>>
>> Lacking resources to manage this large number of issues, I think 
>> that
>> we have to set an expiry date on the JIRA reports (and close them 
>> upon
>> expiry), unless they pertain to confirmed bugs.
>
> If you want to throw a sequence of numbers my direction I can collate
> them into something more manageable.

Do you mean something different from what I propose here below?

You can find old issues by setting a search in JIRA like this one:
-----
   project = MATH AND status in (Open, "In Progress", Reopened) and 
created < "2013/01/01"
-----

Regards,
Gilles

> -Rob
>
>>
>> There could perhaps be a single open JIRA report with links to all
>> issues resolved as "Unresolved", just in case some future 
>> contributor
>> wants to revisit whatever had been raised in the past but could not 
>> be
>> completed.
>>
>> What do you think?
>>
>> Gilles


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

Re: [Math] Expiry date for old issues

[Rob Tompkins <ch...@gmail.com>]

I would think something along the lines of: if an issues has not been apparently worked or or clearly commented on in some number of release cycles (maybe 2 or 3), then the issue should be able to be closed.

> On Apr 23, 2016, at 6:26 AM, Gilles <gi...@harfang.homelinux.org> wrote:
> 
> Hi.
> 
> Browsing through the project's open issues is becoming a huge time sink.
> Commons Math is crumbling under its own weight in this area too.
> 
> Some of the old issues are feature requests that are unlikely to be
> implemented in the near future.
> Others contain discussions and/or patches not updated in years, and are
> thus likely outdated wrt to the current line of development.  Just
> checking whether anything can be salvaged would anyways take a lot of
> time which nobody is prepared to do, as anyone can see from the recent
> activity in the project.
> 
> Some reports should have been resolved/closed long ago but were not,
> probably because of the sheer number of pages to look at.
> 
> Lacking resources to manage this large number of issues, I think that
> we have to set an expiry date on the JIRA reports (and close them upon
> expiry), unless they pertain to confirmed bugs.

If you want to throw a sequence of numbers my direction I can collate them into something more manageable. 

-Rob

> 
> There could perhaps be a single open JIRA report with links to all
> issues resolved as "Unresolved", just in case some future contributor
> wants to revisit whatever had been raised in the past but could not be
> completed.
> 
> What do you think?
> 
> Gilles
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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