[edk2-announce] March Community Meeting Minutes

[edk2-announce] March Community Meeting Minutes

[stephano]

An HTML version is available here:
https://www.tianocore.org/minutes/Community-2019-03.html

License Review
------
The draft of the RFC is out, comments welcome. See details here:
https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html

And V2 is here:
https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html

Please contact Stephano or the stewards directly if you have questions 
or comments you would not like shared on the list.

GitHub Pull Requests
------
Stephano has taken an action item to work with the Kubernetes community 
to see what trade-offs and benefits they experience using GitHub. 
Kubernetes is one of the largest open source projects currently using 
GitHub for patch reviews. It is notable that a git module "request-pull" 
exists, and the kernel gives directions on how to use these "git style" 
of pull requests:

https://www.kernel.org/doc/html/v5.0/maintainer/pull-requests.html

However, it has been noted by the community that GitHub is a much more 
modern way of doing patch review, hence the continued exploration of 
this topic. The main blockers are still the inadequate archive of 
information in email as well as a limited offline workflow. These 
blockers have been brought up by multiple community members, and 
Stephano is currently looking for a work around.

EDK II Repo Updates
------
We would like to take a cue from Project Mu and improve the structure of 
the EDK II repository. In the coming weeks, Ray will be leading a lot of 
the work in terms of retiring packages or moving them to more suitable 
locations. The stewards have had these conversations over the past few 
years, and we now have the bandwidth to start moving forward on many of 
these efforts. We have already introduced edk2-platforms that has 
platform specific code. Now we need to start moving all platform 
specific code to that repo. We will also be working on retiring the 
edk-compatibility package, as well as removing support for EDK1-style 
capabilities from the BaseTools. There are other work areas around the 
emulator package regarding running edk2-firmware as an application under 
Windows, Linux, or macOS, which would let us retire the NT32 package. 
Adding platform initialization specifications was intended to replace 
the Intel Framework content. We'd like to see all the platforms move off 
of those and use the PI defined interfaces so we can remove them. The 
goal is that in the end the edk2 repository should be platform agnostic, 
and only keep a few emulation environments to support future 
integrations. OVMF and the emulator package will still be integral so 
that any future CI can check for backwards compatibility against those 
platforms.

Bug Triage
------
Bug triages began in February. See here for details:
https://www.tianocore.org/bug-triage/

Please join us as we explore bugs and features every 2 weeks.

Groups.io
------
Progress is continuing as Laszlo and Stephano have almost finished their 
review. Things look promising. We should be able to move to Groups.io 
for our mailing list solving the attachment and white-listing problems. 
We can also use Groups.io for document storage and design review 
discussions / doc storage.

Design Meetings
------
Design meetings are schedule to begin in March. An announcement will go 
out sometime in the coming week or so.



Thank you all for joining. As always, please feel free to email the list 
or contact me directly with any questions or comments.

Kind Regards,
Stephano Cetola
TianoCore Community Manager

Re: [edk2-announce] March Community Meeting Minutes

[Rebecca Cran]

On 3/11/19 10:33 AM, stephano wrote:

>
> Stephano has taken an action item to work with the Kubernetes 
> community to see what trade-offs and benefits they experience using 
> GitHub. Kubernetes is one of the largest open source projects 
> currently using GitHub for patch reviews. It is notable that a git 
> module "request-pull" exists, and the kernel gives directions on how 
> to use these "git style" of pull requests:


I took a look at the Kubernetes project a few days ago, and there are a 
couple of things we might _not_ want to copy, since they look to me to 
obfuscate things.

For example, the git log:


commit 50bf223a0545a121dc202de8fad673402b8ebde6 (HEAD -> master, 
origin/master, origin/HEAD)
Merge: 4ea48886df c5c4cd2580
Author: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Date:   Mon Mar 11 12:00:15 2019 -0700

     Merge pull request #75224 from neolit123/certs-print-key-on-phase

     kubeadm: print key inside the upload-certs phase of init

commit 4ea48886df2e0830daa2384f6fe57dd55b8dbb51
Merge: 8477c486a8 58c7b5de9c
Author: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Date:   Mon Mar 11 09:39:40 2019 -0700

     Merge pull request #75008 from nikopen/patch-4

     rebase audit-proxy image to distroless/static

commit 8477c486a81c1094440cf7c78d6be5c52b0828c4
Merge: 6ec5a7d337 fa926ed6e0
Author: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Date:   Mon Mar 11 09:39:27 2019 -0700

     Merge pull request #74652 from cofyc/fix72500

     Delay CSI client initialization


You can't see without following the pull request *who* committed the 
change.  There are almost 1000 open pull requests, which is something we 
probably want to try and avoid. They also seem to have _lots_ of labels. 
I wonder if there's a cleaner way of handling them?


Also, about groups.io, I wonder if I might want to investigate their 
support for using our own domain, so people don't have to remember that 
the mailing list and documents are on groups.io and not tianocore.org?


--

Rebecca Cran

Re: [edk2-announce] March Community Meeting Minutes

[stephano]

On 3/11/2019 1:55 PM, Rebecca Cran wrote:

> You can't see without following the pull request *who* committed the 
> change.  There are almost 1000 open pull requests, which is something we 
> probably want to try and avoid. They also seem to have _lots_ of labels. 
> I wonder if there's a cleaner way of handling them?

Agreed. We spoke about some of the downsides of pull requests in the 
last stewards meeting. Linus did a fair job of detailing some of these here:

https://github.com/torvalds/linux/pull/17

I'm going to work with EDK II maintainers to be sure that we do not move 
to a model that makes their life harder (e.g. 1000 open pull requests).

> 
> 
> Also, about groups.io, I wonder if I might want to investigate their 
> support for using our own domain, so people don't have to remember that 
> the mailing list and documents are on groups.io and not tianocore.org?
> 

Yes, I'm hoping to use our own domain with groups.io. Once we've 
completed the testing phase I'll bring this up to my boss(es) to get 
approval for an enterprise account ($200/month). That will allow us to 
use something more friendly with tianocore.org.

Cheers,
Stephano

Re: [edk2-announce] March Community Meeting Minutes

[stephano]

On 3/11/2019 9:33 AM, stephano wrote:
> Stephano has taken an action item to work with the Kubernetes community 
> to see what trade-offs and benefits they experience using GitHub. 

I realized earlier today that rust-lang also uses GitHub style pull 
requests:

https://github.com/rust-lang/rust/pulls

Since they certainly qualify as a popular open source project I'll add 
them to my list of communities to contact. :)

Cheers,
Stephano

Re: [edk2-announce] March Community Meeting Minutes

[Rebecca Cran]

On 3/11/19 4:20 PM, stephano wrote:

> On 3/11/2019 1:55 PM, Rebecca Cran wrote:
>
>> You can't see without following the pull request *who* committed the 
>> change.  There are almost 1000 open pull requests, which is something 
>> we probably want to try and avoid. They also seem to have _lots_ of 
>> labels. I wonder if there's a cleaner way of handling them?
>
> Agreed. We spoke about some of the downsides of pull requests in the 
> last stewards meeting. Linus did a fair job of detailing some of these 
> here:
>
> https://github.com/torvalds/linux/pull/17
>
> I'm going to work with EDK II maintainers to be sure that we do not 
> move to a model that makes their life harder (e.g. 1000 open pull 
> requests).
>
>>
>>
>> Also, about groups.io, I wonder if I might want to investigate their 
>> support for using our own domain, so people don't have to remember 
>> that the mailing list and documents are on groups.io and not 
>> tianocore.org?
>>
>
> Yes, I'm hoping to use our own domain with groups.io. Once we've 
> completed the testing phase I'll bring this up to my boss(es) to get 
> approval for an enterprise account ($200/month). That will allow us to 
> use something more friendly with tianocore.org.


Thanks! Sorry for the skepticism, I've just had experiences in the past 
with new systems being introduced which made work more difficult (e.g. a 
commercial code review tool: several teams avoided it by using Review 
Board or Gerrit instead).


-- 
Rebecca Cran