Re: [PEAR-QA] Very old bugs and requirements

On Sat, Aug 20, 2011 at 8:42 AM, Stelian Mocanita <
[email protected]> wrote:

> Hello everyone,
>
> I was talking to Ken over irc and since I have quite some time on my hands,
> I could give a hand here and there with the bugs. While discussing what
> goes
> where, I went over the bugs list and there are quite some old ones, dating
> back from 2003.
>
> Some of the requests address packages that are no longer maintained by
> anyone or "closed" due to something newer and better out there. With this
> in
> mind I have some propositions on the bugs list:
>
> - 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 dunno about unmaintained == wontfix on all bugs -  quite frankly it would
severely annoy me as a reporter to be waiting "ages" then to have my (legit)
bug closed.... because no one can be stuffed fixing it.

Old report -> feedback/patches wanted I can live with more.

Superceeded packages - I agree, wontfix.

- 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 have thought about a 'deactivate patch' db flag/control just to clean up
this report.
http://pear.php.net/qa/packages_orphan_patches.php

With the still maintained-but-has-patch; I agree that reviewing them is a
good step.
http://pear.php.net/qa/patches_on_open_reports.php

With this cleanup we would end up with a much smaller bugs list and taken
> one by one we might even get to the bottom of it. Since I only have karma
> for the package I maintain, I am volunteering to the first part.
>
> What do you guys think?
>
> Perhaps one of the more effective ways is to contribute to tools that make
QA releases easier; or have better reporting/stats/etc.

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

Ideas include:
 - A report of the packages with the oldest, most bugs - indicating it's
probably unmaintained.

 - A tool to fork an old; stable package (Foo) into a revamped version
(Foo2); where it has PHP4 compatibility.
This would:
Clone dir structure into a new packge (either SVN or github)
Update package.xml
Refactor all methods to include public/private/protected prefixes
Renaming classes
Fixing docblocks ('PHP Version 4 & 5 -> PHP Version 5")

- A report or tool to fix dir structure of an old package & update the
package.xml

- A report / tool that picks up package 1.0.xml and migrates it to package
2.0 (see https://wiki.php.net/pear/packages/migration)

- A  tool that checks if a package has no unit tests; and attempts to
autogenerate stubs (
http://www.phpunit.de/manual/current/en/skeleton-generator.html)

- A one click migrate to github button or script