Re: [RFC] - How QA Team will work. Rev 1.

Hi Helgi, here two comments... > Orphaned Packages > The QA team can use the above stated rules to determining if > a package is orphaned. The core QA team gets lead rights on > all orphaned packages until the original maintainer returns > or a new maintainer is found. That will require a new global maintainer: "PEAR QA", which would be merely a pseudo user. QA core members would automatically (via karma) have all rights over that package. Once a new maintainer is found, or the original maintainer returns, "PEAR QA" will be removed from the list of maintainers, and the karma will automatically be revoked. General rights that have been granted to the QA team as specified in the PEAR web section will remain untouched. Rights that may be granted to QA, etc. should be defined in a separate RFC once this RFC has been approved. [...] > pear web PEAR web QA subsection [...] > latests decisions. Furthermore here the QA team will be able > to provide interfaces to QA team services. For example here > the QA team could offer an interface for maintainers to > configure the access rights they want to grant the QA team. The access rights can be granted here -- as well as revoked. If the (possibly new) maintainer decides not to allow QA to roll releases anymore, he must have the ability to revoke his permission. > Approving first stable release > The QA team needs to approve the first stable release of any > major version. For this purpose maintainers must contact the > QA team and provide a pear package of the final stable > version. It is up to the QA team to decide if the release is > ready or not. The core QA team will at this point upload the > pear package that was provided by the maintainer. I think it would be best if the maintainer would upload the release, and it would sit on the server till QA approves of it or not. That way, QA could either reject a release, stating a reason, or confirm it. Otherwise pearweb karma will become really complex. Klaus