Very old bugs and requirements

On Sun, 21 Aug 2011, Daniel O'Connor wrote:

>> - go through the old requirements and if the package is no 
>> longer maintained or we have a newer package in pear or 
>> pecl, close it as "won't fix"

I think a request for the reporter to 'reverify' in the case 
of a newer package, and a close if not responded to within say 
a month is perhaps more reasonable, if the bug reviewer is not 
the maintainer, but rather a bug triager without 'inside 
knowledge' of the particular package

If a package is formally 'no longer maintained', the question 
partitions to:  can and will the reporter undertake to 
maintain (really: revive) it [if a package has been 
superceded, it would seem that this too might be noted], and 
again, and a close if not responded to within say a month

If the reporter replies that they lack the skill to undertake 
maintainership, it seems the project 'management' can then 
decide to confirm that the package is well and truly no longer 
maintained, and close the bug with a clear conscience; 
alternatively if it is not obvious to confirm as such, and 
assuming there is an 'itch to scratch', it may in some rare 
cases be revived

> - go through the bugs and see the status of patches. There are a lot of
>> patches submitted by users so part of the job is done
>>
>> That's been done with quite a lot; there's few on the list of unmaintained
> + patch pending. Most of these patches aren't acceptable in the current
> form.

I know that we stabilized a patch found in the comment 
history on a package, and forked, because no-one seemed to 
ACTUALLY be doing maintenance.  It's been a while, but I do 
recall seeking commits [on the list, and privately to one of 
the 'project management'], and never hearing back  ;(

It may be that something to formally act as a catch basin for 
such 'requests for commits' .. maybe as simple aas a new 'bug 
category' <?> .. may be in order

>> What do you guys think?

Moving to time-boxes releases, comes to mind, in the absence 
of a formal feature based release plan

> Unfortunately we've got diminishing manpower and growing manual tasks - so
> doing things by hand imo is tricky to sustain.

As to diminishing personnel ... systemitize adding new blod 
;)

> - A one click migrate to github button or script

Please also then leave a README with a forward pointer, as 
part of that migration process

-- Russ herrold