Re: [edk2-rfc] [edk2-devel] [RFC] EDK II Continuous Integration Phase 1

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

Sean,

There may be many ways to improve the process and reduce
the work maintainers perform.  So these are ideas we can
explore further going forward.  I will add the concept
of a non-maintainer opening the PR to the Wiki.

In order to get the improvements to code quality from CI
enabled as quickly as possible, I recommend we limit PRs
to maintainers.

Thanks,

Mike

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Tuesday, September 3, 2019 10:46 AM
> To: Sean Brogan <sean.brogan@microsoft.com>;
> rfc@edk2.groups.io; Ni, Ray <ray.ni@intel.com>;
> devel@edk2.groups.io; Gao, Liming
> <liming.gao@intel.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Subject: Re: [edk2-rfc] [edk2-devel] [RFC] EDK II
> Continuous Integration Phase 1
> 
> On 09/03/19 19:09, Sean Brogan wrote:
> > Laszlo/Mike,
> >
> > The idea that the maintainer must create the PR is
> fighting the
> > optimized github PR flow.  Github and PRs process is
> optimized for
> > letting everyone contribute from "their" fork while
> still protecting
> > and putting process in place for the "upstream".
> >
> > Why not use github to assign maintainers to each
> package or filepath
> > and then let contributors submit their own PR to edk2
> after the
> > mailing list has approved. Then the PR has a policy
> that someone that
> > is the maintainer of all files changed must approve
> before the PR can
> > be completed  (or you could even set it so that
> maintainer must
> > complete PR).   This would have the benefit of less
> monotonous work
> > for the maintainers and on rejected PRs the
> contributor could easily
> > update their branch and resubmit their PR.
> 
> I'll let Mike respond.
> 
> Thanks
> Laszlo