From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F2FA6138262 for ; Tue, 17 May 2016 11:26:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C61AA224077; Tue, 17 May 2016 11:25:58 +0000 (UTC) Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E14FC224048 for ; Tue, 17 May 2016 11:25:57 +0000 (UTC) Received: by mail-vk0-f43.google.com with SMTP id c189so15466246vkb.1 for ; Tue, 17 May 2016 04:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Usb6NHBlzvP07U/0pjDktuAH15xJu8Z7NL8HlKn05M8=; b=c1Np1cIif/aGyN9s8ey3r0wIXCoGgvX1JlfGYsFd1Eur4U3MemUjd5YBa390J+nCAr TM9Ik/RQV5o4gCi4jAaOErWlD4vDPrqv9HFv32feaoEA+FjMOv1/mv/P2yzaqN9Adt0r 6m5wP7cLnSEwOajdk2EjzydyNTqo32JSLRnn9+8PMNuE++IAEH/r5EGj7w4bbN70hOys mXL+JYExVOPqpBCTQM88Dlfoqz1byp8tYk1BcPZYwBjtxVWIjdSeUnOMaAfIBd/O/xQo dsz8YW9RPk2PM8GiKDeT8Mc/pqdbaattUjkmz0BxhO0qpdq5t0bVcmxF7/5A4xxVWVNr 8oig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Usb6NHBlzvP07U/0pjDktuAH15xJu8Z7NL8HlKn05M8=; b=dRKSKYv3ukQ7VlchQGZ/9js5rvowiR90y42uuuFN8llo8vgE/m2yVIEgAUpgPnIoFN GbgVPnjqCLNfUwZ9GgQEvku0RnfhjtJrSYnEOPGjrpeCiU6iwSGWkzrS+lu+wR1QJKQq k0YisKUDnFQo12zMuxhSWZblE3YoWCObu54+Lu/VOhmFiZe05gVITSuicy2cWa7r4jt+ ofHZNuUMn80kAwltFBC2Z9v6naxKEhVlXAns3oy0Eg0kN2ul2ychqKJSeidfTOTR9T5B V+DXspeJ+8+Ix2nw3yAJD/vyYvwQJPSvICj1ZWuKhzqhAyigZIT75/xrPFtnZGxiHBPa TD6Q== X-Gm-Message-State: AOPr4FU32xcnmvX37Wb8JWZLF1rz0sflhkSUlnWfLEThExYTEKH3A7WuwKsidobkYnUKjY/PIrX+8CDGVn35kA== X-Received: by 10.159.39.231 with SMTP id b94mr334293uab.64.1463484356836; Tue, 17 May 2016 04:25:56 -0700 (PDT) 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 MIME-Version: 1.0 Received: by 10.176.2.46 with HTTP; Tue, 17 May 2016 04:25:37 -0700 (PDT) In-Reply-To: References: <20160516183840.4b241463@gentp.lnet> <20160517084643.GA24972@skade.schwarzvogel.de> From: Pallav Agarwal Date: Tue, 17 May 2016 16:55:37 +0530 Message-ID: Subject: Re: [gentoo-dev] Proposal for changes for the next EAPI version To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=94eb2c122e063944700533080125 X-Archives-Salt: 757aeaa6-4692-43e9-ad4c-5bf58f3d5a52 X-Archives-Hash: bd623173170f67d09b6a6c23a79fa282 --94eb2c122e063944700533080125 Content-Type: text/plain; charset=UTF-8 On Tue, May 17, 2016 at 4:27 PM, Rich Freeman wrote: > On Tue, May 17, 2016 at 5:15 AM, Kent Fredric > wrote: > > On 17 May 2016 at 20:46, Tobias Klausmann wrote: > >> And as for my pet peeve, tests that are known to fail, can we > >> also annotate that somehow so I don't waste hours running a test > >> suite that gives zero signal on whether I should add the stable > >> keyword? Even a one-line hin in the stabilization request would > >> be nice. As it is, I keep a list of known-to-fail packages and my > >> testing machinery tells me to not bother with FEATURES=test in > >> those case. > > > > IMO: Tests that are "expected to fail" should be killed. > > > > That makes sense, though ironically the only specific hypothetical use > case to come up so far was an example of just this situation. A > package is broken in stable, and a test was proposed to detect if > future stable candidates fix the flaw. There would be no point in > delaying stabilization of a package that contains the same error as > the current stable version. > > I don't see any harm in adding support for automated Gentoo-specific > tests, but I am skeptical of how much use they'll actually get. After > all, we started off with the statement that this is for situations > where upstream doesn't provide test suites, and if upstream can't be > bothered, why would we expect a distro maintainer to care more? > > -- > Rich > > Because we are already expecting an arch tester to conduct tests for the package. And knowing what to test is something I expect to come more easily from the maintainer. --94eb2c122e063944700533080125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 17, 2016 at 4:27 PM, Rich Freeman <rich0@gentoo.org> = wrote:
On Tue, May 17, 2016 at 5:15 AM, Kent Fred= ric <kentfred= ric@gmail.com> wrote:
> On 17 May 2016 at 20:46, Tobias Klausmann <klausman@gentoo.org> wrote:
>> And as for my pet peeve, tests that are known to fail, can we
>> also annotate that somehow so I don't waste hours running a te= st
>> suite that gives zero signal on whether I should add the stable >> keyword? Even a one-line hin in the stabilization request would >> be nice. As it is, I keep a list of known-to-fail packages and my<= br> >> testing machinery tells me to not bother with FEATURES=3Dtest in >> those case.
>
> IMO: Tests that are "expected to fail" should be killed.
>

That makes sense, though ironically the only specific hypothetical u= se
case to come up so far was an example of just this situation.=C2=A0 A
package is broken in stable, and a test was proposed to detect if
future stable candidates fix the flaw.=C2=A0 There would be no point in
delaying stabilization of a package that contains the same error as
the current stable version.

I don't see any harm in adding support for automated Gentoo-specific tests, but I am skeptical of how much use they'll actually get.=C2=A0 A= fter
all, we started off with the statement that this is for situations
where upstream doesn't provide test suites, and if upstream can't b= e
bothered, why would we expect a distro maintainer to care more?

--
Rich

Because we are already expecting an arch t= ester to conduct tests for the
package. And= knowing what to test is something I expect to come more
easily from th= e maintainer.

--94eb2c122e063944700533080125--