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

LIMBOURG Arnaud wrote:

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. We have a number of maintainers that don't even do basic QA of their own packages, such as comparing uppercase strings against get_class (i believe 3 or 4 packages do this) Waiting 2 months for a 1 line fix that anyone can make because a maintainer isn't around borders on insanity. Whats the point of having any centralization at all if maintainers aren't getting help on easy fixes they miss.

-joshua eichorn