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.web10.17668.1590168021228542634 for ; Fri, 22 May 2020 10:20:21 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ivAZh7LE; 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=1590168020; 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=b1DP8R77PbeU/+2KiP2F7goCPPlB3CHSg7lNRTmBaCo=; b=ivAZh7LE0o7NQsPaT0QbNMbfDH62uw+eai8WSf+uGj3AnH9i9tcRHiYee6Of8Bg9DFey6j q8RjJ2h5vhW8wZpxB+kZvlnJDp2qsedg1qe+IrIJjUZ4MzxWXKsKIj/m+bWEOeHFO5XBhm wgCl7TED3IfshCGFwoXeWZzLDiWFQCk= 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-33-K561ANBQP2S8_MjGb0IjKg-1; Fri, 22 May 2020 13:20:07 -0400 X-MC-Unique: K561ANBQP2S8_MjGb0IjKg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 480158015CE; Fri, 22 May 2020 17:20:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-40.ams2.redhat.com [10.36.112.40]) by smtp.corp.redhat.com (Postfix) with ESMTP id 432866EA59; Fri, 22 May 2020 17:20:04 +0000 (UTC) Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process To: Bret Barkelew , Andrew Fish Cc: "devel@edk2.groups.io" , "spbrogan@outlook.com" , "rfc@edk2.groups.io" , "Desimone, Nathaniel L" , "Kinney, Michael D" , "Leif Lindholm (Nuvia address)" References: From: "Laszlo Ersek" Message-ID: <4f83ebd0-199b-f352-52c6-14e92891d51c@redhat.com> Date: Fri, 22 May 2020 19:20:03 +0200 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.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/22/20 07:48, Bret Barkelew wrote: > In Mu we have a similar problem of keeping track of what features/bugs > have already been upstreamed and when can they be dropped during an > upstream integration, so that's the more personal interest I have in > such automation. Proposal: - Whenever upstreaming a bugfix or a feature, open an upstream BZ. - In your downstream ticket for the same bugfix or feature, cross-reference the upstream BZ URL. This shouldn't be a normal comment, but a dedicated field. In Bugzilla, there is "See Also" (it can carry a list of URLs). In our own (RH) Bugzilla instance, "See Also" has been replaced with an "External Trackers" list, but the idea is the same. - When you rebase, run a git-log over the upstream commit history being straddled, and collect the upstream BZs referenced. For example: $ git log edk2-stable201911..edk2-stable202002 \ | grep -E -o 'https://bugzilla.tianocore.org/show_bug.cgi\?id=[0-9]+' \ | sort -u This reliably presents the set of upstream BZs that were *touched on* in the subject development cycle, because TianoCore contributors diligently reference BZs in commit messages. Right? :) - Use a script to fetch the fresh status of each of those BZ URLs, because in some cases, "touched on a BZ" does not guarantee "fixed BZ". Some BZs may require multiple waves of patches. Of course, BZs that *have* been fixed will all report RESOLVED|FIXED, because TianoCore contributors and maintainers diligently close BZs as FIXED when the corresponding patches are merged. They even mention the commit range(s) implementing the related code changes, without fail. Right? :) - Once you have your set of Really Fixed (TM) upstream BZs, run a search in your downstream tracker to locate the referring downstream tickets, checking the "See Also" (etc) fields. In a more serious tone: while Red Hat preaches and practices "upstream first", we obviously *do* have downstream tickets for bugfixes and features. And if we are *inheriting* patches for them via a rebase (as opposed to backporting / cherry-picking them), then we benefit from the same kind of linkage. That's why I keep "lecturing" maintainers when they fail to close BZs, and/or to note the subject commit ranges (which I might want to investigate manually). Now, I realize that "git forges" can auto-close tickets when encountering ticket references in merged patches. The problem is that *multiple* patches may reference a ticket and *still* not constitute a complete fix for that ticket -- see my "multiple waves of patches" note above. Automation cannot fully supplant manual ticket wrangling. NB, the above procedure could also help with composing the "feature list" for any upcoming edk2 stable tag. When collecting the URLs, and checking their fresh statuses, also check the "Product" fields. If Product is "TianoCore Feature Requests", then the ticket is a good candidate to name at . Thanks, Laszlo