Re: extremely inactive packages

Gregory Beaver wrote: > Hi all, > > I would like to propose a change to the way we do things here. There > are too many packages whose open bugs are just hanging out waiting to be > fixed. If you find a package with a few open bugs that are simple > fixes, I propose we do this: > > First, check these possibilities: > > 1) When was the last commit? Recent? > 2) When was the last comment on a bug? Recent? > 3) Has the developer been active on any of their packages recently? > > If the answer is "no" to all 3, I suggest that the package be marked as > unmaintained, and if it is marked as unmaintained, any pear developer > with commit access may fix bugs and then QA can make a release. > > As an example: Payment_Clieop has 2 open bugs, both are trivial fixes, > it's been 4 years since a commit, the lead has not been active on any > maintained packages since 2005. > > Another example: PHP_Parser has been inactive for a while, but one of > the lead developers (me) has been active recently on other packages, and > so fails the tests above, and the normal process of package > maintainership (i.e. formal request must be made to commit) is followed. Hi, So based on the uniformly positive feedback, I'd like to amend the procedure above and put it on the QA page. === This procedure affects only packages that are not marked as unmaintained 1) When was the last commit? Recent? 2) When was the last comment on a bug? Recent? 3) Has the developer been active on any of their packages recently? if the answer is "no" to all three, then: 1) send a message to pear-qa@lists.php.net with subject "[UNMAINTAINED] package XXX QA" (replace XXX with the package name). In the message, provide links to cvs.php.net and the bugs list for each package that the maintainer maintains. In the message, state which bugs you will be fixing 2) commit changes to CVS The QA group then will: 1) mark the package as unmaintained 2) do the actual release and decide what the version number should be. Packages marked as "unmaintained" may have fixes committed by any PEAR developer without requesting permission, but the QA group must make new releases. Based on the 3 questions above, the QA group may also choose to mark a package as "unmaintained" on the website. === Sound good? Greg