1 |
On 9/12/18 10:50 AM, Rich Freeman wrote: |
2 |
> On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman <perfinion@g.o> wrote: |
3 |
>> |
4 |
>> Replying to a somewhat random post. There are two separate things here |
5 |
>> that people are discussing here but are not the same thing. |
6 |
> |
7 |
> Three, really... |
8 |
> |
9 |
>> |
10 |
>> 1) We want to know when a package has terrible warnings when installing |
11 |
>> it so we can report upstream and know that something might have gone |
12 |
>> wrong. |
13 |
> |
14 |
> There is also the case where we want these warnings to block |
15 |
> installation, because the risk of there being a problem is too great. |
16 |
> |
17 |
>> |
18 |
>> Stick this in your make.conf: |
19 |
>> PORTAGE_ELOG_SYSTEM="echo save" |
20 |
>> PORTAGE_ELOG_CLASSES="warn error log qa" |
21 |
>> I'm pretty sure toralf's tinderbox already has these enabled but all |
22 |
>> devs should too. |
23 |
> |
24 |
> The problem is that this will make the warnings non-fatal. |
25 |
> |
26 |
> Do we still tell users not to report these kinds of warnings in |
27 |
> bugzilla? If they're the sort we consider serious then we would want |
28 |
> to know about it so that we can address it, vs just waiting for |
29 |
> upstream to fix them in a future release. |
30 |
> |
31 |
> There might be a better solution than -Werror, such as a flag in an |
32 |
> ebuild that makes the existing QA warning fatal and tells the user to |
33 |
> log a bug. |
34 |
> |
35 |
|
36 |
Picking random email. |
37 |
|
38 |
I would like to say I'm glad we can discuss our technical differences |
39 |
like this with both sides expressing their opinion and reasoning. |
40 |
|
41 |
I would hope in the future we start with this path and not with |
42 |
disciplinary action or bugs requesting the removal of commit access. |
43 |
|
44 |
We're showing here we can bring up our points without handing out "QA |
45 |
strikes" or some other type of confrontational action. |
46 |
|
47 |
Mike |