From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 48A40A00BE; Tue, 28 Apr 2020 15:31:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9F3FB4C89; Tue, 28 Apr 2020 15:31:23 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 561142BD8 for ; Tue, 28 Apr 2020 15:31:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588080681; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cVsqeOPwK78gmpGM8ifgD4PgmhxzMV8G5nRroIIxNSk=; b=FiblaxnfqlYxKlK3wJ+9vPeEkYl4Pdp8PgdbwL0zA7fOwU0FBCjPSzz8GSgJS8iQj1BFot ZHpbEX3q1Oe+955XUi1/ID6HvZ/g/Ns3CbyuJUZUU69L26LBxtXyWsbSuDhRPc7+vGnUlk fSVBE873po8ykU4fgZe6J9An93uKj/k= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-7-hbj7-JriMyWVkz6HpOgZNg-1; Tue, 28 Apr 2020 09:31:19 -0400 X-MC-Unique: hbj7-JriMyWVkz6HpOgZNg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0C7BB107ACCA; Tue, 28 Apr 2020 13:31:18 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-114-167.rdu2.redhat.com [10.10.114.167]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 95D951001B0B; Tue, 28 Apr 2020 13:31:13 +0000 (UTC) From: Aaron Conole To: Thomas Monjalon Cc: Ferruh Yigit , David Marchand , "Somalapuram\, Amaranath" , "Kumar\, Ravi1" , "dev\@dpdk.org" , Raslan Darawsheh , Ali Alnubani , dpdklab@iol.unh.edu References: <20200427061145.25039-1-asomalap@amd.com> <22a7429d-067a-4dc1-ca86-c45a776b4d69@intel.com> <529334320.JY4mfKhWER@thomas> Date: Tue, 28 Apr 2020 09:31:12 -0400 In-Reply-To: <529334320.JY4mfKhWER@thomas> (Thomas Monjalon's message of "Mon, 27 Apr 2020 17:00:26 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v1] maintainers: update for AMD xgbe and ccp crypto X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Thomas Monjalon writes: > 27/04/2020 14:58, Aaron Conole: >> Ferruh Yigit writes: >> > [1] Two issues reported >> > a) ninja: build stopped: Error writing to build log: Disk quota >> > exceeded. >>=20 >> This occurs on some of the ARM64 builds. Travis is aware of the issue, >> but don't seem urgently fixing it. :-/ I think we have a series >> outstanding that should be applied to drop those builds for now. > > I saw some "Disk quota exceeded" on x86 static builds. > So I changed my mind, I am not sure dropping only Arm from Travis > is a solution, even temporary. Okay. > >> > b) No output has been received in the last 10m0s, this potentially ind= icates a >> > stalled build or something wrong with the build itself. >>=20 >> This is a future enhancement I need to work on. When a build has jobs >> that are stalled / errored, we need to restart them (at least once). Or >> otherwise flag it. It especially happens when internal travis >> infrastructure fails. > > Yes Travis infrastructure fails. Always. > Travis is free, but it is not a reason to provide a randomly failing tool= . It has been quite useful - it shows us that we still have some incomplete unit tests and also some racy unit tests. I agree, it shouldn't be failing the way it is. > I suggest switching to other platforms like OBS or our community lab, > preferring the most reliable one. OBS and community lab isn't as easy for individual developers to integrate with. One thing that's been useful for me is to push to my github repo and see the results of all the build configurations. It doesn't require much effort from my side to ensure that code works. I don't always do this (but that's my bad habit), but when I do it proves very useful. Maybe the new github-ci (I think it's called 'actions') would be good to investigate. Also, Cirrus-CI lets us test on windows and freebsd. And there's no reason we can't use all of them.