On Wednesday 01 March 2006 21:53, Mark Loeser wrote: > Here is my updated version after some feedback from people: > > * In case of emergency, or if package maintainers refuse to cooperate, > the QA team may take action themselves to fix the problem. > * The QA team may also offer to fix obvious typos and similar minor > issues, and silence from the package maintainers can be taken as > agreement in such situations. > * In the event that a developer still insists that a package does not > break QA standards, an appeal can be made at the next council meeting. > The package should be dealt with per QA's request until such a time that a > decision is made by the council.
one thing i dont think we give enough emphasis to is that our tools arent perfect ... sometimes we utilize QA violations to work around portage limitations ... if you want to see some really sweet hacks, review any of the toolchain related ebuilds and the hacks ive had to add to get cross-compiling to the usuable state that it is today. a handful of them would fall under the 'severe' category i'm sure. and if we want to use the lovely php example, personally i think that given portage's current limitations, the latest dev-lang/php ebuild is probably one of the best solutions that could have been developed, thanks Stuart for all the flak you've had to take over this. also, many games ebuilds break the 'non-interactive' policy by displaying licensing and making the user hit "Y" because portage lacks checks where the user explicitly states what licenses they accept. -mike -- gentoo-dev@gentoo.org mailing list
