From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web12.9668.1600324318590451520 for ; Wed, 16 Sep 2020 23:31:58 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YmtuCWCh; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600324317; 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=1kFa15QijYf1ArzonuqQXPczza6vQ+ObrHlVCGw2KYs=; b=YmtuCWChiBWu25fhDj9LBEkOsq/KPgHqWmBCKtKyastIoWZ0dfvX1RJ2upOZQslVmsRhj5 p55xk2ztmDy/MJaRDuV+wTjYJzNfHTFUSVD7XprjPcffBEU2xlkWSFk2GfbDcTA/RHgo5T AkUP7RvtpYctTmZAa++fdmpdzi7AK/0= 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-459-fl8S7acIPjuxEmIn1V7a8Q-1; Thu, 17 Sep 2020 02:31:48 -0400 X-MC-Unique: fl8S7acIPjuxEmIn1V7a8Q-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 BCA59800471; Thu, 17 Sep 2020 06:31:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-187.ams2.redhat.com [10.36.112.187]) by smtp.corp.redhat.com (Postfix) with ESMTP id 51D8C71775; Thu, 17 Sep 2020 06:31:44 +0000 (UTC) Subject: Re: [edk2-devel] more development process failure [was: UefiPayloadPkg: Runtime MMCONF] To: "Yao, Jiewen" , "devel@edk2.groups.io" , "gaoliming@byosoft.com.cn" , "Dong, Guo" Cc: "marcello.bauer@9elements.com" , "Kinney, Michael D" , "'Leif Lindholm (Nuvia address)'" , "Doran, Mark" , 'Andrew Fish' , "Guptha, Soumya K" References: <20200818082421.6168-1-marcello.bauer@9elements.com> <11b4d671-7c5e-0ef3-0d2f-13ef605f1eaf@redhat.com> <000e01d68c94$bb92d920$32b88b60$@byosoft.com.cn> From: "Laszlo Ersek" Message-ID: <31e807dc-6217-f3b6-995b-ab10f4ce789e@redhat.com> Date: Thu, 17 Sep 2020 08:31:43 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.003 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Jiewen, On 09/17/20 04:31, Yao, Jiewen wrote: > Hi Laszlo, Liming, and Mike > > I appreciate your effort to setup rule and document this *complex* EDK II Development Process. > > I am thinking if we can have a way (a tool) to mandate these process and check if there is any violation. If people makes mistake, he/she knows he/she is making mistake and can correct immediately, instead of letting mistake happens and getting blame later. In such way, we can prevent issue from happening. > > We have old maintainer leaving, new maintainers joining. That is the reality. We can have training for everyone. But we are still human. There are many bugs need to be fixed in the code. How can we expect a perfect process that everyone follows strictly without any violation? > > If we only have few violation, it is OK to stay with it. > But if we continuously have violation, we need retrospect to ask, *why*? Why there is such a process to cause so many violation? > And can we do better? A simpler process? A better tool? while I agree that the current process is not really simple, I'd like to point out some things: - The current complexity exists because we are in a transition period, and so we get to deal with both the workflow we're leaving (= the mailing list based review) and the system we're adopting (= github). This should not last forever. I don't know the exact schedule though. - I think that lack of attention to detail (on the human side) takes a relatively large chunk of the blame. The process at the moment is not simple, but it's exercised every day, every week by some people, so if somebody *wants*, they can get it right by following examples. Look at recent patch series threads that have been merged, recent BZs that have been closed, recent PRs that have been opened and merged. It's a fallacy that adopting a 100% github.com-native patch review workflow will solve all of these issues. There is no replacement for human discipline and attention to detail. In the current process, I *regularly* find pull requests (personal builds or maintainer push attempts) on github.com that fail CI (or merging due to conflicts) and then the submitter never bothers to close or refresh them. I have cleaned up (closed) a *multitude* of such PRs. > I also feel sorry that Laszlo need check by his eye on every PR and catch the violation for us. And I also feel sorry to blame some people who is contributing his/her time to help to maintain the code, review the code, check in the code. > We both feel frustrated. We are all coming her to enable new features or fix bugs to make EDKII better. > > I would like to ask: Is that technically possible to enhance the CI to catch that earlier, as Laszlo point out: > 1) Add patch 0 to PR - can we let CI reject empty description PR? It won't help. See the following bug report: https://bugzilla.tianocore.org/show_bug.cgi?id=2963#c0 While it is technically not empty (the string in comment#0 has nonzero length), it's practically *devoid of information*. People that are annoyed that they are required to write sensible summaries for patch sets and bug reports, will do anything and everything to wiggle out of that requirement. They will create single-sentence PR descriptions, which will allow them to pass the CI check. And the community will be *worse off*, because we will have complicated our CI logic, but the resultant historical records will be just as useless. > 2) Send email - can we let CI send email automatically? Or remind us to send email? github.com *already* sends an email notification when a PR undergoes a state change; that is, when it is merged, or else CI fails. The email is *already* there, people just have to *act* upon it -- run a local "git pull" again, see what the new commit range is, and send a response to the original thread. > 3) update Bugzilla - can we let CI update Bugzilla automatically? Or remind us to update bugzilla? Automatically closing tickets is not implemented between github.com and Bugzilla. It is implemented within github.com (merging a PR can auto-close issue tracker tickets, if you format the commit message corectly). However, auto-closing is *wrong*. It occurs that multiple patch series relate to a single ticket. In such cases, it's possible that 10+ patches are merged for a single ticket, and the ticket should *still* not be closed, because more patches (for the same ticket) are necessary. Only a human can tell when the fix or the feature is considered complete (according to their knowledge at that point in time). > 4) Unicode char - can we add check in patchchecker, to reject predefined format violation? There are many-many classes of unicode code points. It's not easy to express "accept U+003A for punctuation, but do not accept U+FF1A". It's easy to express "accept 7-bit ASCII only", but I think some people might take issue with that, because then their names could not be placed in subject lines in native form. > > I know the new tool/CI cannot be built in one day. And we do improvement step by step. The *real* problem is with the attitude. If a developer cares *only* until their patches are merged, then no tooling will *ever* fix this issue. People need to start caring about the afterlife of their work. When you throw a party, or join one, you stay around for the cleanup afterwards, don't you? When you call a contractor to fix something in or around the house, do you expect them to clean up when they're done, or are you happy cleaning after them? The exact same bad attitude is the reason that - we have botched error paths in programming languages like C, - we have programming languages and libraries that attempt (and *fail*) to clean up resources on errors, "on behalf" of the programmer -- I'm referring to exceptions and destructors in C++, for example. Both of these are symptoms that people *refuse* to deal with the "boring" aspects of the job. Just accept that the party isn't finished until the house and the garden are tidied up, and the furniture is restored to original order. Laszlo