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

"Tomas V.V.Cox" <cox@idecnet.com> a écrit dans le message de news:1385489623.20030813200423@idecnet.com... > 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 :-) > 2 months is WAY too much. > 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? > > 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 > >