Re: [edk2-devel] [edk2] Soft Feature Freeze starts today for edk2-stable201905

["Laszlo Ersek" <lersek@redhat.com>]

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