Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

Dnia 2014-12-08, o godz. 07:27:51
"Anthony G. Basile" <blueness@g.o> napisał(a):

> 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.

Yes, that's exactly what occurred to me! Then I joined QA.

But seriously saying, I didn't mean forcing anything on anyone myself.
I meant starting proper QA process which could eventually hopefully
result in QA prohibiting the use of current eclass in future ebuilds,
and or referring to the Council about switching the default gcc
provider. Of course, that's only the worst scenario.

> 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.

As I already said, the main issue simply can't be fixed this way. It's
not that much *bugs in code in toolchain.eclass* but *what's in
toolchain.eclass*. If we think of eclasses as libraries, then your
library provides main() function. With conditionals for 14 consecutive
releases of your program. And you already told people to link random
stuff to it, and rely on every internal API detail.

-- 
Best regards,
Michał Górny