From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 82264C433F5 for ; Mon, 7 Mar 2022 12:29:29 +0000 (UTC) Received: from localhost ([::1]:59786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nRCUS-0003n2-Lz for qemu-devel@archiver.kernel.org; Mon, 07 Mar 2022 07:29:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39336) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nRCTA-0001hz-QD for qemu-devel@nongnu.org; Mon, 07 Mar 2022 07:28:10 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:33131) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nRCT8-0001kS-CN for qemu-devel@nongnu.org; Mon, 07 Mar 2022 07:28:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646656084; h=from:from:reply-to: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=ppJ34Y3xalgS1idw6VhEHEodY0M6DTgM58ZHF/vPpOM=; b=jLpavokb/gDkfTRkZQcNC+FztKqbTDIAnlHPjV9p+gZJq3QMX/nmW0ksbQBo/ZKSYev+Ut 8vsrG9v/YsB19ZFM906ZL0SEkE8iLmzsioAwFebw7eoaKjEoeeOyPK5FaN7DWfP6GLMCKK gc9kc/xS+ivtenU3q0aYwmCSHy6HBbA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-574-WGxgFLo5P9WYc-Xak9biJQ-1; Mon, 07 Mar 2022 07:27:59 -0500 X-MC-Unique: WGxgFLo5P9WYc-Xak9biJQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4239E801AFE; Mon, 7 Mar 2022 12:27:58 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.133]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0413B2377C; Mon, 7 Mar 2022 12:27:51 +0000 (UTC) Date: Mon, 7 Mar 2022 12:27:49 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Peter Maydell Subject: Re: [PULL 00/33] Abstract ArchCPU Message-ID: References: <20220306130000.8104-1-philippe.mathieu.daude@gmail.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.1.5 (2021-12-30) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Eduardo Habkost , Thomas Huth , Richard Henderson , qemu-devel@nongnu.org, Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Paolo Bonzini , Alex =?utf-8?Q?Benn=C3=A9e?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Mar 07, 2022 at 12:17:24PM +0000, Peter Maydell wrote: > On Mon, 7 Mar 2022 at 12:12, Daniel P. Berrangé wrote: > > A big issue IMHO is that the pain/impact hits the wrong people. > > It is most seriously impacts & disrupts Peter when merging, and > > less impacts the subsystem maintainers, and even less the > > original authors. > > > > If we consider a alternative world where we used merge requests > > for subsystem maintainers just to send pull requests. The subsystem > > maintainer would open a MR and it would be their responsibility > > to get a green pipeline. Peter (or the person approving pulls for > > merge at the time) shouldn't even have to consider a MR until it > > has got a green pipeline. That would put the primary impact of > > unreliable CI onto the subsystem maintainers, blocking their work > > from being considered for merge. This creates a direct incentive > > on the subsystem maintainers to contribute to ensuring reliable > > CI, instead of considering it somebody else's problem. > > CI fails merge isn't really a big deal IME -- I just bounce > the merge request. The real problem and timesink (especially of > CI hours) is the intermittents. I'm saying the intermittents shouldn't be your problem to babysit either though. The subsystem maintainer should own the whole problem of getting the CI into a green state, either by fixing the genuine bugs in the pull, but also by re-trying the jobs on intermittent failure and/or by fixing the non-deterministic pre-existing problems. The person approving the merge to git master shouldn't have to do more than look at the CI results to check they are green and hit the button to apply. GitLab can even enforce this by disabling the ability to apply the merge request until CI is green, to avoid accidentally merging something with bad CI results. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|