From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 869FF1A1E2A for ; Thu, 20 Oct 2016 02:11:43 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C76278AE73; Thu, 20 Oct 2016 09:11:42 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-155.phx2.redhat.com [10.3.116.155]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9K9Behw028721; Thu, 20 Oct 2016 05:11:40 -0400 To: Leif Lindholm , "Kinney, Michael D" References: <20160927011552.20384-1-leif.lindholm@linaro.org> Cc: "Tian, Feng" , edk2-devel-01 , Andrew Fish , "Zeng, Star" , Ard Biesheuvel From: Laszlo Ersek Message-ID: <6116e38c-1e15-1f34-10b8-e2a4135b79c2@redhat.com> Date: Thu, 20 Oct 2016 11:11:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 20 Oct 2016 09:11:43 +0000 (UTC) Subject: Re: [PATCH] MdeModulePkg: add ARM/AARCH64 requirements to .dsc X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 09:11:43 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/20/16 10:17, Leif Lindholm wrote: > On 19 October 2016 at 23:56, Kinney, Michael D > wrote: >> Yes. Please commit. > > Thanks - pushed as b752e8a3fb685ae04155bf6a34a9aac83810613f > >> I see this was rb 3 weeks ago, and was not picked up by the MdeModulePkg maintainers. >> >> Are you aware of any tools to help us notice if a commit like this is missed so >> we can ping the maintainers? > > Not really. It'd be tricky to pick up on which patchsets should go in > and which shouldn't. > Although I'd be happy to hear suggestions from others for tools to > help maintainers keep track. Wait, is someone asking for my opinion? :) So here's how I track patches. I use two methods that have worked for me over a long time. I'm also aware of a third method. The third method is running a patchwork server. I've never seen this method work outside of Red Hat, that is, a downstream environment where some people are actually tasked with handling patches. Quite a few upstream projects use patchwork, but none I know does a great job with it. I could be wrong, so corrections are welcome -- I'm not naming project names here on purpose. The first method that I personally use is starring / tagging / marking emails in Thunderbird. It works exceedingly well. I can track patches that I have to review / commit, patches I posted and wait for review for, and any kind of discussion really. I can (and do) easily track messages that are older than 6 months. Thunderbird has a good local metadata search feature, so I can quickly round up all my tagged messages, sort them based on this or that column (like date or mailing list folder), and choose what needs kicking or work. In a partly reviewed series, Thunderbird tags (or the IMAP "F" flag I think) can be applied on the patch level as well. The second method is Bugzilla (obviously). Bugzilla has awesome searches (saved searches as well). People just need some discipline in using it: - report bugs for issues (might be overkill sometimes, but it varies with the attention threshold of the people of the specific project what issues permanent tracker BZs should be reported for) - religiously cross-link mailing list threads with the BZ -- if a new thread that is related to the issue is started on the list, immediately follow up with the BZ URL on-list, *plus* add a new BZ comment with the URL of the thread starter (from the mailing list archive) - whenever a patch or patch series is posted, be sure to reference the BZ (by URL) in the commit message (Ref: ... or Fixes: ... or Bugzilla: ...), and equally importantly, link the blurb message of the series into the BZ as well, in a new comment - When the series is committed & pushed, capture the commit range in the BZ, in a new comment, before the BZ is closed. (Also, close the BZ.) For both methods, get into the habit of searching your mailbox for tagged messages every week (at the rarest) and running your saved Bugzilla searches. Send reminders as necessary. The most important thing about both methods is that incoming email ("events") have to be triaged immediately. It is not necessary to act upon the final R-b immediately when it arrives -- that is, when that R-b appears, the maintainer need not commit the patch or series immediately. He or she *does* have to update the status in his mailbox or in Bugzilla immediately, so that later searches can turn up the ready-to-commit series. Think of this as hardirq vs. softirq (bottom half): you need to handle new messages in your mailbox with a hardirq handler, for triaging and tagging. The actual work can happen later, in the softirq handler. If the hardirq handler drops interrupts, there's nothing for the softirq handler to act upon later. ("you" == "generic you", obviously) Thunderbird, Bugzilla and Patchwork are clearly not the only possible tools, but tooling does make a difference -- both tooling and discipline are necessary. For example, GitHub, Outlook, GMail are all quite inappropriate for mailing list-based distributed development. (You could argue that many people are drawn to GitHub's web-based proprietary workflow -- or I could mention Gerrit to I guess? -- exactly because their crappy mail user agents don't let them interact with each other sensibly on lists.) ... Thanks, this felt good. ;) Laszlo