From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id BA824138359 for ; Fri, 6 Nov 2020 09:14:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 13D93E0819; Fri, 6 Nov 2020 09:14:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CA8C0E07F1 for ; Fri, 6 Nov 2020 09:14:37 +0000 (UTC) Message-ID: <2b0ecad117d3f27e9250d22ffe9249ac67a59f7f.camel@gentoo.org> Subject: Re: [gentoo-dev] A feedback about the CI bug reporting system From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Fri, 06 Nov 2020 10:14:30 +0100 In-Reply-To: <2044703.irdbgypaU6@spectre> References: <2044703.irdbgypaU6@spectre> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-mJAW1zG8Lw7MjpiNEL8h" User-Agent: Evolution 3.36.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: b75faf46-e3b9-4561-bc86-157827b61176 X-Archives-Hash: 423c6c259b4bff7d8d4c2e59cabb8d86 --=-mJAW1zG8Lw7MjpiNEL8h Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-11-06 at 08:21 +0100, Agostino Sarubbo wrote: > Hello all, >=20 > 6 months have been passed after the CI system started to file bug reports= . > ~ 4700 bugs have been submitted >=20 > We _know_ that atm is not possible to set a specific summary, instead a= =20 > generic summary is used in case of compile failures and test failures. > There are also some documented limitations. 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. > If there aren't much commits, usually you get the bug after 30 minutes af= ter=20 > the commit and this looks to be nice. >=20 > Since there are conflicting opinions I would like to know if you find it= =20 > useful or not. >=20 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. 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. 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. 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. 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. To summarize, what your tinderboxing effort lacks is really a human touch. You seem to have set the goal to file as many bugs as possible automatically. I disagree with that, as I would like this effort to focus on helping developers, not pursuing them. This requires a human touch, not a machine lord. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-mJAW1zG8Lw7MjpiNEL8h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl+lE/dfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA6kAAf/dZEwaaRiHCM+zsTJMx3k7WMsV1fd/q8c5MSVRlqXIjImjgpKG8DgBmd+ 8D33nIFlG/Wu+zdI7fLxz+ar/ZZsFGEsALiH1AWfjKNM/r1lGp7e/yiMUkCmM8rH epDzjSeNnAXzeQ9ckzYujKcmBs6CDoObeqhL+hPrDsdjYlaTpm3Ia28Cer0dToEE QDL2HJRXRjeL8plWHxQK6PWdOjSjW4heAg7d+H9ZgyrCDOj/lz0dymHrMscTpy6T 52uDff+N3l4YkYnk9tk6Bj62CE2ZTjerfmfdihiV8lkUzAyutLPfChhlqYcT/DK5 YGgpZFLd6Qa0C6vAqixIrhHxC5DY9A== =cZCy -----END PGP SIGNATURE----- --=-mJAW1zG8Lw7MjpiNEL8h--