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

On Wednesday, August 13, 2003 17:15, Lukas Smith wrote: >> From: Derick Rethans [mailto:derick@php.net] >> Sent: Wednesday, August 13, 2003 12:56 PM >> >> I wouldn't go into the "minimal turn around time", as there might be >> plenty of very good reasons why a developer doesn't answer. I don't > see >> anything wrong with the current rules. The package is the developer's >> responsibility, other people shouldn't touch it (without approval) of >> that developer. (This is also one of the reasons xdebug is not in PECL >> CVS btw). > This is not a sufficient solution. > Bugs have to be fixed! Packages cannot linger forever without them being > expanded to cover our needs if such needs come up. > Period. > There is no arguing around it. There are a few ground rules we have that > make this necessary. > We are not hot script ... when putting in your code you accept certain > responsibilities not the least of which is code quality. 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 :-) Anyways, in **ALL** cases, you **MUST** get a clear authorization from the lead developer before even thinking on commiting anything to others package. For packages that are clearly in "alpha and unmaintained" state for years, we have to decide how to clearly mark them as "deprecated or orphan" and drop them from the main tree at the pear web. That's one thing the pear group could decide on. -- Tomas V.V.Cox mailto:cox@idecnet.com