public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	"Wu, Hao A" <hao.a.wu@intel.com>,
	"edk2-devel@lists.01.org" <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
Date: Mon, 25 Mar 2019 19:33:18 +0100	[thread overview]
Message-ID: <2a2efa72-9d30-dad5-d97f-bcb8f4abe837@redhat.com> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F5B9C711DA@ORSMSX112.amr.corp.intel.com>

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


  reply	other threads:[~2019-03-25 18:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25  5:28 [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg Hao Wu
2019-03-25  5:28 ` [PATCH v2 1/3] OvmfPkg: Drop the ISA Floppy device support Hao Wu
2019-03-25 10:42   ` Laszlo Ersek
2019-03-25  5:28 ` [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver Hao Wu
2019-03-25 11:22   ` Laszlo Ersek
2019-03-26  2:52     ` Wu, Hao A
2019-03-25 12:00   ` Laszlo Ersek
2019-03-25 17:30     ` Kinney, Michael D
2019-03-25 18:33       ` Laszlo Ersek [this message]
2019-03-25 20:02         ` Kinney, Michael D
2019-03-26 11:19           ` Laszlo Ersek
2019-03-25  5:28 ` [PATCH v2 3/3] OvmfPkg: Add a build flag to select ISA driver stack Hao Wu
2019-03-25 11:20   ` Laszlo Ersek
2019-03-25  8:28 ` [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg Ard Biesheuvel
2019-03-25 10:58 ` Laszlo Ersek
2019-03-25 11:29   ` Laszlo Ersek
2019-03-26  2:49     ` Wu, Hao A
2019-03-26 10:14       ` Laszlo Ersek
2019-03-26 11:21         ` Laszlo Ersek
2019-03-26 10:09     ` Julien Grall
2019-03-26 11:53       ` Laszlo Ersek
2019-03-26 13:03     ` Anthony PERARD
2019-03-26 15:01       ` Laszlo Ersek
2019-03-26 15:14         ` Anthony PERARD
2019-03-26 15:15         ` Laszlo Ersek
2019-03-27  0:20           ` Wu, Hao A
2019-03-27  3:37             ` Laszlo Ersek
2019-03-27  5:28               ` Wu, Hao A

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2a2efa72-9d30-dad5-d97f-bcb8f4abe837@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox