Hi Laszlo, The review of the content based on the edk2-stable201903 is intended to make sure there are no mistakes on that content so I can adjust for the final patch series. A mistake would be applying new license to files that should not be updated, or not applying the license to a file that should have been updated. You provided valuable feedback on those two points for OvmfPkg in V1.
I agree it will be simpler if we can guarantee no file add/remove commits occur in a window leading up to April 9, 2019. So it is not a freeze on all content. It would be a freeze on commits that add/remove files. How does a ~1 week of no commits of file add/remove starting April 1 sound? I can produce a V3 on April 2 for final review by all package maintainers. I would of course rebase the patch series on April 9 and also verify that no files were added/removed. Thanks, Mike > -----Original Message----- > From: Laszlo Ersek [mailto:[email protected]] > Sent: Monday, March 25, 2019 11:33 AM > To: Kinney, Michael D <[email protected]>; Wu, > Hao A <[email protected]>; [email protected] > Cc: Justen, Jordan L <[email protected]>; Ard > Biesheuvel <[email protected]>; Ni, Ray > <[email protected]> > Subject: Re: [PATCH v2 2/3] OvmfPkg: Add an Super IO bus > driver > > On 03/25/19 18:30, Kinney, Michael D wrote: > > Hi Laszlo, > > > > I do not think content added before April 9, 2019 > > should use the new license type. We need to let the > > 30-day review period complete and make sure all > feedback > > is resolved. > > Good point. > > > We will handle files added between the edk2- > stable201903 > > and April 9, 2019 in a final patch series with an easy > > way for all maintainers to see what has changed > between > > those two points. > > Hm. From the reviewer side, this is not optimal. The > patch set (and the > individual patches themselves) are pretty big, and doing > incremental > reviews on them is taxing. Regardless of whether the > incremental review > needs to target an updated "full" patch set, or just an > incremental > patch set (for new files), the reviewer needs to re- > evaluate whether > something is now missed, after the introduction of new > files. > > Instead, I'd prefer a "lock" period for OvmfPkg and > ArmVirtPkg, between > (a) my next (hopefully, final) review for the license > conversion > patches, and (b) the pushing of those patches. For that, > I see two options: > > - We could delay Hao's work (and all other patches that > add files to > OvmfPkg and ArmVirtPkg files) until after April 9. We > can of course > collaborate on feature / bugfix patches meanwhile, it's > just that the > final versions of *those* should be reposted with > updated license > blocks. Incrementally reviewing *those* changes feels a > lot easier to me. > > - Alternatively, I could delay my next (hopefully, > final) review of the > license conversion patches until reasonably close to > April 9, until > which "review point" new files could be added freely, to > OvmfPkg and > ArmVirtPkg. (This wouldn't eliminate the "lock period", > just make it > shorter for contributors.) > > IOW, this is similar to the stabilization period / > feature freezes, just > much more intrusive, because everything has to be > switched at the same > moment. > > I'd like to reach an understanding on our approach > before I start > reviewing "[edk2] [PATCH V2] Change EDK II to BSD+Patent > License". > > Thanks > Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
