Re: [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver

["Kinney, Michael D" <michael.d.kinney@intel.com>]

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:lersek@redhat.com]
> Sent: Monday, March 25, 2019 11:33 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; Wu,
> Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>; Ni, Ray
> <ray.ni@intel.com>
> 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