1 |
IN REPLY TO Michał Górny that didn't keep me CC'ed as requested: |
2 |
|
3 |
>I do disagree with your presumption that this needs to be automated. |
4 |
>The whole point behind providing a service is that you should be ready |
5 |
>to dedicate *your* time into the service. However, we keep feeling that |
6 |
>you assume that your time is too precious, and it is better to waste |
7 |
>a little bit of everybody else's time. This is why Toralf's effort is |
8 |
>much more appreciated. |
9 |
|
10 |
I don't guess that my time is precious and your time is not. |
11 |
|
12 |
If you take a look at the amount of bugs you will see that it is not possible |
13 |
for an human to file those bugs manually. |
14 |
So if is not clear, the concept would be: I invest my time to find bugs that |
15 |
have not been discovered by others, but you give me an hand to find the exact |
16 |
issue by analyzing the build log helping yourself with ctrl-f function of the |
17 |
browser |
18 |
|
19 |
|
20 |
|
21 |
|
22 |
|
23 |
|
24 |
>I am concerned about new test scenarios being run and QA warnings being |
25 |
>reported without proper research and documentation. It's not exactly |
26 |
>helpful to spam people with hundreds of bugs without a single proper |
27 |
>document explaining how to resolve issues. This just provokes people to |
28 |
>do apply bad workarounds, not to mention wasting everyone's time. |
29 |
|
30 |
Usually, qa notices are not something invented by me. So in other words you |
31 |
are saying that while I'm reporting a QA notice that comes from portage I |
32 |
should explain how to solve the problem? |
33 |
I guess you should resolve the problem upstream. Each QA notice must have |
34 |
something that explain how to solve that. |
35 |
While considering the above, usually to help I add something useful at the end |
36 |
of the bug. |
37 |
|
38 |
|
39 |
|
40 |
|
41 |
>The compiler-rt bugs were one example of both of my points being valid. |
42 |
>You've started running a specific scenario without researching |
43 |
>the underlying problems first, and you have missed entirely that you're |
44 |
>reporting a lots of bugs for the same root issue. People have gotten |
45 |
>hundreds of bugs with no clear explanation how to fix them. The only |
46 |
>reason we didn't get hundreds of horrible 'fixes' is that the problem |
47 |
>was probably too hard to workaround. |
48 |
|
49 |
Did you forget how the compiler-rt class of bugs started? |
50 |
Let me remind that: |
51 |
- I had the tinderbox with no load and nothing to check |
52 |
- I thought about a round with compiler-rt |
53 |
- Since _YOU_ are the most active behind the llvm stuff I asked to you if you |
54 |
know how to use the compiler-rt stuff ( I have the IRC logs if you really have |
55 |
a memory lapse ) |
56 |
- You and Afrever answered me about the C/LD flags to use. |
57 |
- After the first report (it was an error never seen by me) I asked: Hey is |
58 |
this a report related to compiler-rt? You answered yes |
59 |
- I asked if it was worth to create a bug tracker |
60 |
- you confirmed |
61 |
- I started to file the other bugs |
62 |
|
63 |
So would be better to say to the community that: |
64 |
- I have asked to you "how-to" |
65 |
- You shared the necessary info |
66 |
- I started to file bugs (~50 and not hundreds as you said) |
67 |
- You (or someone else) discovered that it is broken without libcxx |
68 |
|
69 |
|
70 |
|
71 |
|
72 |
>DISTUTILS_USE_SETUPTOOLS is yet another example of a minor catastrophe. |
73 |
>Sure, I could've added more information to the check message. However, |
74 |
>there is a major difference between people slowly getting QA warnings |
75 |
>from a new check and people getting hundreds of bugs telling them to fix |
76 |
>these warnings. This is a difference between involving a thinking |
77 |
>person, and a semi-automated process that doesn't account for obvious |
78 |
>mistakes. |
79 |
|
80 |
|
81 |
DISTUTILS_USE_SETUPTOOLS is yet another example of memory lapse. |
82 |
|
83 |
Did you forget how the DISTUTILS_USE_SETUPTOOLS class of bugs started? |
84 |
Let me remind that: |
85 |
- During the stabilization process I saw these DISTUTILS_USE_SETUPTOOLS |
86 |
warnings |
87 |
- I asked if was fine to report them |
88 |
- You answered that was fine, but avoid the cases where the warning was in |
89 |
stable but was fixed in ~arch |
90 |
- after few weeks or month ( I don't remember exactly) I was asked by aballier |
91 |
to file this class of bugs. |
92 |
|
93 |
Since tinderbox runs always the latest version of the software, I started to |
94 |
file bugs |
95 |
|
96 |
When you started to see these bugs you also requested to show the exact value |
97 |
of DISTUTILS_USE_SETUPTOOLS that I immediately added. |
98 |
|
99 |
So what I would to point out is: If someone reads this thread think that I |
100 |
autonomously started posting nonsense bugs, but in reality these bugs were |
101 |
requested and initially also resolved. |
102 |
|
103 |
So if at some point you discovered that these bugs are nosense because of |
104 |
upstream changes, I have no fault. |
105 |
|
106 |
|
107 |
|
108 |
|
109 |
>AR bugs is another class of controversy. There is one thing to ensure |
110 |
>that build systems respect AR for toolchain work, there is another to |
111 |
>assume that it's fine not to have 'ar' archiver on the system. And yes, |
112 |
>I do realize there are other people involved in this bad idea that |
113 |
>apparently now you need an arch-specific toolchain to unpack |
114 |
>the archives inside Debian packages. |
115 |
|
116 |
So this is something that points out that the situation is not clear, it's not |
117 |
me, the tinderbox or the CI. |
118 |
|
119 |
|
120 |
|
121 |
|
122 |
|
123 |
>I am also concerned about the sheer number of bugs caused by missing |
124 |
>dependencies. Sure, I do find it valuable to get reports of missing |
125 |
>dependencies and fix them in my free time. But I disagree that |
126 |
>stabilizations and keywordings should keep being blocked on problems |
127 |
>that are unlikely to ever hit real user systems. |
128 |
|
129 |
I really agree with you, so can you share all cases where you seen this |
130 |
problem? |
131 |
I'm pretty sure you are confusing what comes from the CI and what comes from |
132 |
the arch test machines. |
133 |
|
134 |
|
135 |
Agostino |