On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile <bluen...@gentoo.org> wrote: > On 12/07/14 08:18, Michał Górny wrote: >>>> >>>> I will also be happy to work on replacing >>>> the new versions of original sys-devel/gcc completely. With QA process >>>> against toolchain.eclass if necessary. >>>> >>> Let's get the list of QA issues so I at least can work towards a >>> toolchain-r1.eclass if you're not interested in going that way. Also, I >>> take the QA issues seriously, but threatening a QA intervention against >>> toolchain and then acting by forking is heavy handed. QA actions >>> against the current codebase is understandable. >>> >>> So to sum, I'd like to see the QA issues (and others) address in the >>> current approache and toolchain.eclass. Since we can make mistakes and >>> since toolchain is fragile, I suggest a toolchain-r1.eclass where we can >>> test (just change the inheritance in gcc ebuilds for testing) and >>> finally, when we're happy, do the switcheroo. >> >> First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to >> understand and track. If you can remove it and make gcc into proper >> ebuilds that can get revision-level changes, we can discuss. >> > > Hey! why don't I join QA so I can also "fix" eclasses that I find > "intrusive". Let's not make QA the final refuge of those who want to push > through their preferences. > > To proceed forward, you have bugs open against toolchain.eclass. The > practice is to submit the patches to this list for review. If after awards > you have community support, commit despite the maintainer's objections. > Having obtained community support, you will have much more legitimacy > against reverts. I can't speak for the whole council, but I would support > you under such circumstances. I cannot support a position where QA simply > asserts itself. When/if an appeal percolates up to the council, I will side > with the maintainer under the argument that the commit to the eclass was not > sufficiently reviewed. >
++ regarding how QA should operate. I have no issues with him forking the ebuild and doing things his own way though. -- Rich
