Re: Very old bugs and requirements

Hello all,

I just got back in town, with little bit more delay than expected and went
through all you guys discussed here.

I believe that going through old packages and trying to reach the reporters
and get a status of a particular report is a viable solution, we could even
automatize this process so we don't put in loads of men hours to get there.

The Github migration automation is all so cool, having the amount of
contributions on github versus pear. If noone is working, or planning to
work on this, I am volunteering as long as we can start a discussion thread
on this topic and figure out how and what exactly we want.

Regards,
Stelian

On Sun, Aug 21, 2011 at 11:04 PM, R P Herrold <[email protected]> wrote:

> 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
>