From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 22 May 2019 01:54:09 -0700 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 mx1.redhat.com (Postfix) with ESMTPS id 161B13082E23; Wed, 22 May 2019 08:53:54 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-230.rdu2.redhat.com [10.10.120.230]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1A41567C68; Wed, 22 May 2019 08:53:50 +0000 (UTC) Subject: Re: [edk2-devel] [edk2] Soft Feature Freeze starts today for edk2-stable201905 To: "Ni, Ray" , "devel@edk2.groups.io" Cc: "Gao, Liming" , "Kinney, Michael D" , "Cetola, Stephano" , Andrew Fish , Leif Lindholm References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E44C967@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C1580D1@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <1c12501e-bb5a-477e-6749-f898ee59b93c@redhat.com> Date: Wed, 22 May 2019 10:53:50 +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: <734D49CCEBEEF84792F5B80ED585239D5C1580D1@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Wed, 22 May 2019 08:53:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/22/19 10:28, Ni, Ray wrote: >>> 110d4729b58e EmulatorPkg: Add NetworkPkg/NetworkPkg.dec as the >> package >>> dependency >> >> Invalid, same as commit 911efe279ec3 above. >> >> ... No, wait, this is worse: this patch had not received *any* review feedback >> on the list: >> >> http://mid.mail-archive.com/20190520130920.9464-3-liming.gao@intel.com >> >> but it was committed with Ray's R-b. I don't understand. >> > > Laszlo, > The "R-b" thing is my fault. When Liming reminded me to review the patch, I replied "directly" > to Liming's mail but forgot to add "devel@edk2.groups.io" to the CC address line. > And I just noticed that when I saw Liming forwarded my reply mail out to the public. > > Maybe we need to set edk2 repo read-only to ordinary developers after soft-freeze starts. > Only stewards have the rights to push the changes. This is one mitigation that crossed my mind, yes (not necessarily a restriction to stewards, but some kind of restriction). OTOH, I certainly want to highlight the other option, namely reworking the feature freeze definitions. I had originally created / suggested those as a customization of the similar QEMU definitions (= soft and hard feature freeze), and our initial variants were never meant as "final" -- we should consider them "work in progress", like many other aspects of our workflow. It's plausible that the current SFF / HFF definitions are not a good fit for the edk2 community. Personally, I'm open to re-investigating them. The community should please suggest changes. Some projects adopt a release policy that says, "it's done whenever it's done", and they don't make a release until a handful of critical features are completed. Maybe that's a better fit for edk2 -- I don't know. > But I am not sure whether github supports this feature. I think push rights can be managed individually, by project owners. So technically I think push rights for most maintainers could be revoked *temporarily* by the edk2 project owner, when the SFF is entered. Once the stable tag is dropped, the push rights could be re-instated. (Just this technical possibility doesn't imply of course that it would be a *good* idea. For example, if push rights can indeed only be managed at the individual level, it's quite easy to make mistakes for the project owner -- revoke too many rights, revoke too few rights, restore too few rights, or even grant a push right as part of "restoration" that has never existed before). Some other projects implement this with subsystem maintainer trees, and pull requests (*NOT* necessarily *GITHUB* pull requests!), and merges. Namely, only a really small group of people have push rights to the central repo. Those people merge branches from subsystem maintainers, and push the merge commits to the central repo's master branch. In turn, the subsystem maintainers collect and organize relevant patches from the mailing list into "queue" branches in their personal subsystem repositories. Once a "queue" branch is reasonable in size, and is smoke-tested, the subsys maintainer submits a pull request to a "chief" maintainer. During the feature freeze(s), the "chief" maintainers would only merge such a pull request if the subject "queue" branch contained only eligible patches. > Or maybe we could create a branch when soft-freeze starts, and every push on the master > will be audited and cherry-picked by stewards. On the date of release, the master branch > will be discarded and the branch created before becomes master. Technically this could work, but I see too much potential for confusion (for consumers too). People that pull from the central edk2 repo would have to stay up-to-date on the "current" master branch. Or else, we'd have to rename branches, but that's even worse: it would cause non-fast-forwardable HEAD movements on the local master branches of consumers. Thanks, Laszlo