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.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
