Description: ------------ It seems to be a trend to go through bug reports, fix the problem and close the bug reports, which is all good, but doing the actual release is often forgotten. For example, atm we have Validate_US, last release mid 2005, has around 4 or 5 bugs fixed and some features added according to the bug system. What QA needs is a page to monitor if a package has closed bugs / features, legit ones but hasn't made a release in X months, IMHO it should be around 6 months max but we can also have 3 months and up, each with it's own row and listing packages, something along those lines. This will give QA a better oversight and allows them to poke the right devs about releasing so bug fixes get into the wild. We can achieve this with the Closed Since Last Release feature in the bug tracker. We can perhaps do a cron job that sends out an email to devs and pear-qa when we're over X months, I suggest this will be sent out 1x a month along side the bug summary report but due not this is not something like "Release or else!" thing, mostly just a gentle reminder about if the dev didn't just forget to release or if there are some troubles that QA could assist in resolving. Any additions, comments ?

Great idea. I'm all for it.

The SQL part is ready, it turn out to be fairly light so I might not do a cronjob and the emailing part is not needed, at least for now, QA should handle it personally since it might be too much for devs since they are already being spamed with the monthly bug summary Any opinions ?

I like the idea of it being a manual effort by QA, because that puts some level of "on the spot human judgment" into the hopefully-not-too-frequent need to contact a dev directly about a package. I think a dev is more likely to respond to a personal email from a qa dev rather than act on a cron email.

yeah you are right about that, I noticed couple of false positives for example: Bug was closed as Closed instead of Bogus, talking to the maintainer he feels like it should be closed since the user was happy with the advice even if the bug was bogus, not much we can do about that and that's something we have to spot by our selfs, no amount of programming will find that out for us.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Committed a working file with table sort (html tables) and such; Answer on the ML if there's anything further.