RE: [PEAR-DEV] commiting bug fixes to other peoples packages (was RE: [PEAR-DEV] #25060 [NEW]: Math_Integer/Integer/gmp.php uses raisError () instead
of raiseError())

> > What we would need is something like "qa-releases". This is, if a > > package starts getting a lot of bug reports and the author doesn't > > answer in let's say 2 months, then the qa-team could create a branch > > of the package, apply patches and release a "qa team modified > > packages" out of any oficial state. It's like the Debian > guys do, they > > modify packages, send patches to the author and release their own > > version. Of course we would need a "qa team" prior to this :-) > > > 2 months is WAY too much. The release of a qa modified could happen in a month during the year, two during summer. Time-span can be decided on later. The important thing would be to make clear that it is a qa modified package. > > Anyways, in **ALL** cases, you **MUST** get a clear > authorization from the > > lead developer before even thinking on commiting anything to others > > package. > > Even QA members? QA members will not be there to apply patches on packages. That is why there are maintainers and developers. You cannot expect QA members to have an inside out knowledge of each and every package in PEAR. What appears as a small patch can have deep consequences, only the package maintainer/developers/contributors can see that. Therefore QA members cannot apply patches without being explicitly told so (a mail, IRC should not be accepted) by the maintainer. Arnaud.