On 12/08/14 07:32, Rich Freeman wrote:
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
Forking code does not address the QA issues currently against
toolchain.eclass. The two issues are orthogonal and I don't think I
connected them in my emails. I disagree with forking but have no right
to obstruct it and would not. In that respect, I'm simply voicing my
opinion as a dev. However regarding how QA should operate, I am
operating with the guidelines of gentoo self-governance.
--
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
