1 |
On 12/08/14 07:32, Rich Freeman wrote: |
2 |
> On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile <blueness@g.o> wrote: |
3 |
>> On 12/07/14 08:18, Michał Górny wrote: |
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 |
>>> First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to |
20 |
>>> understand and track. If you can remove it and make gcc into proper |
21 |
>>> ebuilds that can get revision-level changes, we can discuss. |
22 |
>>> |
23 |
>> Hey! why don't I join QA so I can also "fix" eclasses that I find |
24 |
>> "intrusive". Let's not make QA the final refuge of those who want to push |
25 |
>> through their preferences. |
26 |
>> |
27 |
>> To proceed forward, you have bugs open against toolchain.eclass. The |
28 |
>> practice is to submit the patches to this list for review. If after awards |
29 |
>> you have community support, commit despite the maintainer's objections. |
30 |
>> Having obtained community support, you will have much more legitimacy |
31 |
>> against reverts. I can't speak for the whole council, but I would support |
32 |
>> you under such circumstances. I cannot support a position where QA simply |
33 |
>> asserts itself. When/if an appeal percolates up to the council, I will side |
34 |
>> with the maintainer under the argument that the commit to the eclass was not |
35 |
>> sufficiently reviewed. |
36 |
>> |
37 |
> ++ regarding how QA should operate. |
38 |
> |
39 |
> I have no issues with him forking the ebuild and doing things his own |
40 |
> way though. |
41 |
> |
42 |
> -- |
43 |
> Rich |
44 |
> |
45 |
|
46 |
Forking code does not address the QA issues currently against |
47 |
toolchain.eclass. The two issues are orthogonal and I don't think I |
48 |
connected them in my emails. I disagree with forking but have no right |
49 |
to obstruct it and would not. In that respect, I'm simply voicing my |
50 |
opinion as a dev. However regarding how QA should operate, I am |
51 |
operating with the guidelines of gentoo self-governance. |
52 |
|
53 |
-- |
54 |
Anthony G. Basile, Ph.D. |
55 |
Gentoo Linux Developer [Hardened] |
56 |
E-Mail : blueness@g.o |
57 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
58 |
GnuPG ID : F52D4BBA |