IN REPLY TO Michał Górny that didn't keep me CC'ed as requested: >I do disagree with your presumption that this needs to be automated. >The whole point behind providing a service is that you should be ready >to dedicate *your* time into the service. However, we keep feeling that >you assume that your time is too precious, and it is better to waste >a little bit of everybody else's time. This is why Toralf's effort is >much more appreciated.
I don't guess that my time is precious and your time is not. If you take a look at the amount of bugs you will see that it is not possible for an human to file those bugs manually. So if is not clear, the concept would be: I invest my time to find bugs that have not been discovered by others, but you give me an hand to find the exact issue by analyzing the build log helping yourself with ctrl-f function of the browser >I am concerned about new test scenarios being run and QA warnings being >reported without proper research and documentation. It's not exactly >helpful to spam people with hundreds of bugs without a single proper >document explaining how to resolve issues. This just provokes people to >do apply bad workarounds, not to mention wasting everyone's time. Usually, qa notices are not something invented by me. So in other words you are saying that while I'm reporting a QA notice that comes from portage I should explain how to solve the problem? I guess you should resolve the problem upstream. Each QA notice must have something that explain how to solve that. While considering the above, usually to help I add something useful at the end of the bug. >The compiler-rt bugs were one example of both of my points being valid. >You've started running a specific scenario without researching >the underlying problems first, and you have missed entirely that you're >reporting a lots of bugs for the same root issue. People have gotten >hundreds of bugs with no clear explanation how to fix them. The only >reason we didn't get hundreds of horrible 'fixes' is that the problem >was probably too hard to workaround. Did you forget how the compiler-rt class of bugs started? Let me remind that: - I had the tinderbox with no load and nothing to check - I thought about a round with compiler-rt - Since _YOU_ are the most active behind the llvm stuff I asked to you if you know how to use the compiler-rt stuff ( I have the IRC logs if you really have a memory lapse ) - You and Afrever answered me about the C/LD flags to use. - After the first report (it was an error never seen by me) I asked: Hey is this a report related to compiler-rt? You answered yes - I asked if it was worth to create a bug tracker - you confirmed - I started to file the other bugs So would be better to say to the community that: - I have asked to you "how-to" - You shared the necessary info - I started to file bugs (~50 and not hundreds as you said) - You (or someone else) discovered that it is broken without libcxx >DISTUTILS_USE_SETUPTOOLS is yet another example of a minor catastrophe. >Sure, I could've added more information to the check message. However, >there is a major difference between people slowly getting QA warnings >from a new check and people getting hundreds of bugs telling them to fix >these warnings. This is a difference between involving a thinking >person, and a semi-automated process that doesn't account for obvious >mistakes. DISTUTILS_USE_SETUPTOOLS is yet another example of memory lapse. Did you forget how the DISTUTILS_USE_SETUPTOOLS class of bugs started? Let me remind that: - During the stabilization process I saw these DISTUTILS_USE_SETUPTOOLS warnings - I asked if was fine to report them - You answered that was fine, but avoid the cases where the warning was in stable but was fixed in ~arch - after few weeks or month ( I don't remember exactly) I was asked by aballier to file this class of bugs. Since tinderbox runs always the latest version of the software, I started to file bugs When you started to see these bugs you also requested to show the exact value of DISTUTILS_USE_SETUPTOOLS that I immediately added. So what I would to point out is: If someone reads this thread think that I autonomously started posting nonsense bugs, but in reality these bugs were requested and initially also resolved. So if at some point you discovered that these bugs are nosense because of upstream changes, I have no fault. >AR bugs is another class of controversy. There is one thing to ensure >that build systems respect AR for toolchain work, there is another to >assume that it's fine not to have 'ar' archiver on the system. And yes, >I do realize there are other people involved in this bad idea that >apparently now you need an arch-specific toolchain to unpack >the archives inside Debian packages. So this is something that points out that the situation is not clear, it's not me, the tinderbox or the CI. >I am also concerned about the sheer number of bugs caused by missing >dependencies. Sure, I do find it valuable to get reports of missing >dependencies and fix them in my free time. But I disagree that >stabilizations and keywordings should keep being blocked on problems >that are unlikely to ever hit real user systems. I really agree with you, so can you share all cases where you seen this problem? I'm pretty sure you are confusing what comes from the CI and what comes from the arch test machines. Agostino
