From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web09.3342.1575363394230104537 for ; Tue, 03 Dec 2019 00:56:34 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EzFom/hs; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575363393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jE5JI6xyTXe2ClmBLqJoAuZeSnm/fAWEFIDPIc3CXgI=; b=EzFom/hs7M2w0qJo5wulkOUyL/vKrGlrotJg8ltdgRLQIVJMdFnciWGG2qIkJ74y+W+fxC QYb5WhZFdqNytaM4UKuDDBCZHHKHp76hLj1BNb9C7AqoxYuKThFMgNXqYiF50joXRuEBiR dQ4m0d1kxCYbc12Z9+gb7gd2uUnKdHU= 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-103-3SX0KzTLO7CP1tV0mewQqg-1; Tue, 03 Dec 2019 03:56:29 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B3ACE1005509; Tue, 3 Dec 2019 08:56:27 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-183.ams2.redhat.com [10.36.117.183]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6ADCA5DA60; Tue, 3 Dec 2019 08:56:26 +0000 (UTC) Subject: Re: [edk2-devel] EDK II Maintainers - EDK II CI is now active on edk2/master To: "Kinney, Michael D" , "devel@edk2.groups.io" , Sean Brogan , Bret Barkelew , "Gao, Liming" References: <545f1da9-a998-1095-57f9-085cbd535596@redhat.com> <184dbbde-0916-7e09-476c-de700cc57dc5@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Tue, 3 Dec 2019 09:56:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: 3SX0KzTLO7CP1tV0mewQqg-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/02/19 20:55, Kinney, Michael D wrote: > So my question still stands. What notifications would > you like to see if we have the use case of a single PR > with multiple rounds of reviews and a transition from > a PR without the 'push' label to a PR with a 'push' label? Thank you for explaining. In this case, I think it would be helpful if, whenever another email notification were sent out about a PR, the subject of that email contained an auto-generated part that advertized the push label's presence on the PR, at that time. OTOH... It's also possible that I'm approaching this wrong. After all, before we adopted github.com for pushing, a maintainer would just go ahead and push post-review (with no *automatic* email notification about the fact), and then we'd expect that maintainer to report back under the patch review thread ("pushed as commit range ..."), and/or close the BZ ticket with a similar comment. (And then there would be an auto-generated bugzilla email about that.) My point being, maybe I shouldn't even *read* these github.com notifications at all. I'm not sure if they give me useful information. (When the PR is ultimately merged, we *still* require the above kind of closing comment in Bugzilla, from the maintainer -- thus the originally needed information is still provided, just like before.) It's just that, *if* I attempt to read the github.com emails, *then* they confuse me (for example because they don't expose the push label). If we consider this specific kind of PR that we have adopted for edk2 a (practically) "maintainer-internal", mechanical, action, then I guess I might as well want to unsubscribe from those notifications. After all I'm still subscribed to BZ emails, and I'll see the resultant commit range noted there (through the comment that the assignee adds manually, when they close the BZ). Is it possible for a tianocore group member to "unwatch" PRs? Thanks! Laszlo