From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 47983AC181E for ; Mon, 26 Feb 2024 16:01:22 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=lZi3iZcz/zELx77MxaMZRY5EeYXqDRYgywia4M73JV8=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1708963280; v=1; b=c78Uvaa8AF13QfuZIGOhfQ2u5r+DcJU47qoVnOmeRdtXgAoF8elcUV0fq63gAkSZe473oFNx 2vETE4+XKz+RBAQ9x8A65jlA2scp1lWjOvgBAZpLrFlbJxWvIbnkDNywPc9QdKUIJD1yv79dbIg incmttemuceKuhheWWA4wuQI= X-Received: by 127.0.0.2 with SMTP id GSNvYY7687511xy7H03bD3TH; Mon, 26 Feb 2024 08:01:20 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.23971.1708963280289242068 for ; Mon, 26 Feb 2024 08:01:20 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-671-B2sRSPe5O3-SH7XyxFomvg-1; Mon, 26 Feb 2024 11:01:14 -0500 X-MC-Unique: B2sRSPe5O3-SH7XyxFomvg-1 X-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6C3C885A597; Mon, 26 Feb 2024 16:01:14 +0000 (UTC) X-Received: from [10.39.194.99] (unknown [10.39.194.99]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F3558C1D36C; Mon, 26 Feb 2024 16:01:12 +0000 (UTC) Message-ID: Date: Mon, 26 Feb 2024 17:01:11 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v3 0/6] UefiCpuPkg/MpInitLib: Add support for multiple MP_HAND_OFF HOBs To: Joey Vagedes , "devel@edk2.groups.io" , "kraxel@redhat.com" Cc: "Ni, Ray" , Rahul Kumar , Oliver Steffen , "Kinney, Michael D" , Sean Brogan References: <20240222160106.686484-1-kraxel@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: mNC0t9RvnrHWFcdATqSmHiR4x7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=c78Uvaa8; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io Hi Joey, On 2/26/24 16:41, Joey Vagedes wrote: > Hi Lazlo, >=20 > I just looked at the pipelines - Looks like everything is fine, there is = just currently a backup of runners of jobs in the runners. It is common for= jobs that end in CODE_COVERAGE to appear frozen in queued status, but this= is expected as this job not queued until all others have finished, which m= eans it gets put at the end of the list of pipelines to execute. >=20 > Taking a look at all the runners (https://dev.azure.com/tianocore/edk2-ci= /_settings/buildqueue?_a=3DconcurrentJobs [Click "Microsoft Hosted", "View = in-progress jobs"]), I don't see any runners that are frozen, which is why = it appears it's just a backup. >=20 > I'll continue to monitor. thanks -- meanwhile I've also found the blockage, just from a different perspective. I've known for a while that it is not ideal to have multiple PRs open at the same time with the "push" label set. They will either compete for resources (slow), or one will block the other ("queued" state); however, the main annoyance is that once the first PR gets merged, the HEAD of the master branch will move for all the other PRs, and then those PRs will fail to merge even if their CIs run to completion. So in such cases, the maintainer needs to notice the problem in the first place (possibly after having waited for 30+ minutes), then perform a manual rebase (using the github web UI or a local rebase + force push), and then pray that their next attempt will get to the front of the queue. It would be much better if: - *either* the "preempted" PRs rebased themselves automatically to the new master HEAD, and restarted the CI + merge train, - *or*, if at least one PR with "push" were in progress at the time of the maintainer creating a new PR with "push", the CI run wouldn't even *start* -- instead, the maintainer would *immediately* get information about being blocked (and about the inevitable need to rebase later, once that "other" -- earlier-filed -- PR completes). Now, I've been trying to implement strategy#2 myself, by checking the "open PRs" view (with an eye towards the "push" label among those PRs) just before submitting a PR myself. I did that this time as well, but didn't see any concurrent push-PR. That's why I was confused -- first I didn't understand what blocked my CI tasks, and then I didn't understand what had preempted (=3D de-synced) my PR. When I fetched locally afresh, I found two new commits, but didn't understand where those had come from, given that I couldn't see any push-PR concurrently to mine. *However*, searching my edk2-devel folder for the subjects of those suddenly appearing new commits, I figured out the problem: PR was created in *December* last year, but Liming set the "push" label on it only ~2 hours ago. In other words, PR#5187 was the one to hold up and preempt mine. So, why did I not see it in the "open PRs" view? (Because, as I wrote above, if I had seen it, I wouldn't have submitted mine in the first place -- I'd have known it would be useless, due to the master branch moving forward anyway!) Well the reason I didn't see PR#5187 (donning the "push" label at that) was that PR#5187 had been *old as heck*, and so it simply didn't make the first page of the "open PRs" listing! I didn't expect two months old PRs to be merged. So, my lesson from this is: it's not the plain "open PRs" view that I need to check, when implementing approach #2 myself. Instead, I have to explicitly search for open PRs with the "push" label: https://github.com/tianocore/edk2/labels/push Thanks! Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115973): https://edk2.groups.io/g/devel/message/115973 Mute This Topic: https://groups.io/mt/104510905/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-