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