Re: QA process

From: "Lukas Smith" <smith@backendmedia.com> > Hi, > > Currently there is few PEAR QA can really do besides nagging maintainers. > > What I envision is a system where PEAR QA has the ultimate control about how > packages get listed within the PEAR services. While the maintainer maintains > ultimate control over his package. However the PEAR Group can decide to > revoke/add maintainership to a package (for example if PEAR QA asks for this > and provide enough evidence to make this step necessary). Furthermore PEAR > QA gets its own (sub)channel (once we have channel support) to publish QA > releases. This is just a basic idea. That sounds great! How about the possibility that QA can do an emergency stop for a release (e.g., a BC-breaking release like Console_Getopt 1.1) without deleting it. To get it activated again, the maintainer would have to appeal to the Pear Group. Console_Getopt really demonstrated the BC problem well. Some people do an upgrade and then everything breaks. I wonder how often it happened between when we noticed the problem (cf. http://marc.theaimsgroup.com/?l=pear-dev&m=107073335402291&w=2 ) and when the package was removed (cf. http://marc.theaimsgroup.com/?l=pear-dev&m=107079564808690&w=2 ) over 15 hours later. That's not a good thing, imho. QA needs to be able to freeze a release instantly. Of course, we need more people on the QA team, as well. As it is, I don't have all that much time I can put into this, but I'll do my best. Regards, Klaus > I will work on an RFC to flesh these basic ideas out. > > Regards, > Lukas Smith > smith@backendmedia.com > _______________________________ > BackendMedia > www.backendmedia.com > berlin@backendmedia.com > > Linn Zwoch Smith GbR > Pariser Str. 44 > D-10707 Berlin > > Tel +49 30 83 22 50 00 > Fax +49 30 83 22 50 07 > > -- > PEAR QA Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >