TianoCore Community Meeting Minutes - Feb 6

TianoCore Community Meeting Minutes - Feb 6

[Soumya Guptha]

[-- Attachment #1: Type: text/plain, Size: 5932 bytes --]

Community Meeting Minutes: 2-6-20

Agenda:
Thanks to Stephano Cetola for an excellent job driving TianoCore community. Stephano has transitioned to a new role outside Intel.
Soumya Guptha from Intel is the new Community Manager and will drive the TianoCore Community activities.


  1.  FOSDEM Conference
     *   Presentations from our community members:

                                                               i.      Capsule update by Brian Richardson

                                                             ii.      Code first concept by Leif

                                                           iii.      35-40 attendees and they were well received

     *   We will share more details on the presentations during the next community meeting.



  1.  Code first RFC stewards meeting update - Mike Kinney
     *   Leif has shared on the mailing list
     *   We will do EDKII staging repository, inside the staging branch in that repository. Soumya add the link
     *   ECR updates need to be done
     *   We need to fully integrate, validate
     *   Code First RFC

https://edk2.groups.io/g/rfc/message/231

Community Action: Read the RFC and provide feedback if you have any opinions from your engineering teams by next week

Discussion from the community (Felix): As soon as spec is ready, post the links to the spec in the UEFI forum.
Open: we need to identify the sponsor who can take it to the UEFI forum. Suggestion is to review the spec and propose this in the forum



  1.  Q1 Stable tag update - Soumya/Mike covered updates from Liming Gao

  *   Soft freeze for Q2 is scheduled for Feb 14th.
  *   One of the Q1 Stable tag features - boot guard is moving to Q2
  *   All features are listed in https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.
  *   The first feature BootGuard TOCTOU vulnerability (CVE-2019-11098) (https://bugzilla.tianocore.org/show_bug.cgi?id=1614). Its solution is changed. This feature is moving to Q2 Stable tag.
  *   Other features have been fixed except for New BaseCryptLib instances to compile independently from callers<https://bugzilla.tianocore.org/show_bug.cgi?id=2420>. Its patch is under review.




  1.  Ideas for Q2 stable tag from Stewards meeting - Mike Kinney

RISCV

     *   Line ending conversion in Q2 stable tag

  *   Developer github changes may need to occur. Changes around first 2-4wks of Q2
  *   Once the fork is available (by end of Feb), we need community to review, provide feedback if there is any impact.

     *   Submodule conversion in Q2 stable tag

  *   There a few places in EDK2 repository carrying copies. Plan is to modularize and its easier for bug fixes.
  *   Ex: compression and decompression code - we will do a review of this
  *   Targeted during Q2. We will have RFCs and Bugzilla entries.

     *   Wanting RISCV into Q2 stable tag after the above two.

  *   We have several patches around RISCV. Plan is to integrate these as part of Q2 release


     *   Code First comments

https://edk2.groups.io/g/rfc/message/232

https://edk2.groups.io/g/rfc/message/235



     *   Community Action:

  *   We are planning for Stable Tag for Q2 - Everyone start thinking and send your thoughts to Liming Gao
  *   We need the community to be engaged and suggest features for Q2, Q3, Q4. If you like to see any features added, create a Bugzilla entry and work with Liming Gao (intel) for adding those features and to discuss further.


     *   Open: In the next design meeting - when we have a new UEFI spec, request from the community to ask the community for new features and create a long term roadmap. Soumya to pass this feedback to Ray.



  1.  EDKII Open Source Unit test framework - (Mike Kinney)

     *   Collaborative effort from Intel & Microsoft
     *   Background:
Microsoft contributed framework to run tests from UEFI shell
Intel contributed HBFA (Host Based Firmware Analysis)
These two frameworks were combined and simplified to make it simple for developers to write unit tests

     *   This is for a low-level API testing
     *   Supports Host Environments for CI agent testing
     *   Supports Target Environments (PEI, DXE, SMM, UEFI Shell)
     *   Focused on testing interfaces, libraries, and modules
     *   Includes cmocka to support mocked interfaces


Community action:

  *   Stewards would like the community to start writing Unit tests for open source FW and start adding test results on the releases.
  *   Please look at the details. If you are developing new content or maintaining existing content, please consolidate and write the unit tests in this framework, so we can standardize the unit test process.



  1.  Upcoming events:

  *   UEFI Plugfest - Most of the stewards and few other Intel folks plan on attending (Brian, Soumya, Mike Kinney etc..)



  1.  Opens from the Community Attendees:
     *   Opens from Felix:

  1.  Product releases that other companies have may not be aligned with stable tags.
     *   Add a tag - whether it's a feature, bug fix - get an email discussion going (Felix)
  2.  Different email clients have challenges to extract patches. Ex: Due to company policy, some of them need to use outlook, how do we extract those patches?

  *   Felix to start an email conversation on this. We can discuss in the mailing list to understand what other companies are doing or if we need to change something in our development process.

     *   Open from Phillippe

  *   Today we submit patches to the mailing list. The maintainers send a response to the mailing list.
  *   Requesting a change - to get an email notification to the submitter and the list in the same list when the maintainers commit to the patch.
  *   Phillippe to enter the request in Bugzilla for further discussion.





[-- Attachment #2: Type: text/html, Size: 35835 bytes --]

Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6

[Sean]

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

Soumya,
I would like to add three things to community discussions especially around governance and process.

1. RFC: The RFC process seems to get only minimal comments and a lot gets lost in the noise of the lists.  There isn't a good "final" state where all approved RFCs can be seen.  The process is entirely driven by the submitter and thus there is little consistency.   I wanted to highlight another project and how they handle this. https://github.com/rust-lang/rfcs ( https://github.com/rust-lang/rfcs ) As a casual observer it is very easy to review their RFCs (in flight and approved/rejected) as well as understand how to create and submit one if so desired.  The tooling is just git/github so it is familiar to the target audience and has a strong ability to track progress, show history, and be backed up like any code project.  They also leverage github issue tracker for pre rfc conversation and discussions.

2. Bugs/Features/Releases:  First the bug triage and scrub is not very well attended.  I know it is hard to get a ww audience together on a call but i think part of the goal was to offer a public process and a place to learn/discuss.  Is there a better way that still meets those goals?  Secondly, the number of bugs that get discussed is pretty small and the list of open bugzillas are grower faster than the triage effort.  Third, the results are pretty minimal.  Usually a change in owner and a very short comment asking the owner to look at it is the result of the triage.  There is sometimes good conversation (assuming knowledgeable parties are in attendance) but this is impractical to capture into the bugzilla while still keeping forward progress.   Finally, as an submitter of a lot of open/unconfirmed bugs it is not very easy to understand the owners priorities and when the bug will be fixed and merged to master/stable tag. I am happy to contribute effort to making a new process but want to understand if others are frustrated by this as well.

3. Discussions: I wanted to know if anyone has experience with user forums like https://www.discourse.org/.  Again the rust community uses this and it is a pretty nice interface for async communication that doesn't involve mail server and client configuration challenges, corporate policies, and the noise of email.

[-- Attachment #2: Type: text/html, Size: 2527 bytes --]

Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6

[Rebecca Cran]

On 2/14/20 11:25 AM, Sean via Groups.Io wrote:

>
> 3. Discussions: I wanted to know if anyone has experience with user 
> forums like https://www.discourse.org/.  Again the rust community uses 
> this and it is a pretty nice interface for async communication that 
> doesn't involve mail server and client configuration challenges, 
> corporate policies, and the noise of email.


For real-time communications, I think many organizations now use Slack 
(https://slack.com).


-- 
Rebecca Cran

Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6

[Laszlo Ersek]

On 02/14/20 19:25, Sean via Groups.Io wrote:
> Soumya,
> I would like to add three things to community discussions especially around governance and process.
> 
> 1. RFC: The RFC process seems to get only minimal comments and a lot gets lost in the noise of the lists.  There isn't a good "final" state where all approved RFCs can be seen.  The process is entirely driven by the submitter and thus there is little consistency.   I wanted to highlight another project and how they handle this. https://github.com/rust-lang/rfcs ( https://github.com/rust-lang/rfcs ) As a casual observer it is very easy to review their RFCs (in flight and approved/rejected) as well as understand how to create and submit one if so desired.  The tooling is just git/github so it is familiar to the target audience and has a strong ability to track progress, show history, and be backed up like any code project.  They also leverage github issue tracker for pre rfc conversation and discussions.

I agree that RFCs get sorely little attention from the community.

... From my personal perspective, it's not because the RFCs are not
visible -- I simply don't have time to even *understand* most RFCs for
their merits. For example, I checked out Microsoft's VariablePolicy
slides. The design seemed systematic and I appreciated that, it's just
that I couldn't bring myself to make half-cooked comments (regardless of
forum), because those wouldn't do justice to the topic, and I simply
couldn't commit to a deeper involvement.

I can imagine that others appear to ignore several RFCs due to similar
(capacity) reasons.

> 2. Bugs/Features/Releases:  First the bug triage and scrub is not very well attended.  I know it is hard to get a ww audience together on a call

Personal angle again:
- synchronous communication hampers my throughput
- got quickly demotivated by perceiving significantly less effort from
others

Bug triage is a thankless job.

> but i think part of the goal was to offer a public process and a place to learn/discuss.  Is there a better way that still meets those goals?  Secondly, the number of bugs that get discussed is pretty small and the list of open bugzillas are grower faster than the triage effort.  Third, the results are pretty minimal.  Usually a change in owner and a very short comment asking the owner to look at it is the result of the triage.  There is sometimes good conversation (assuming knowledgeable parties are in attendance) but this is impractical to capture into the bugzilla while still keeping forward progress.

Can you please clarify this suggested conflict (between capturing good
technical discussion in the BZ tickets, and "forward progress")?

I think Bugzilla tickets are the best place to capture the focused
analysis of a bug. I write a *lot* of text in Red Hat bugzillas (most of
them are public, luckily!) -- I want to document my own "adventure" with
the issue, even if most paths prove dead-ends in the end. How does that
conflict with "forward progress"?

>   Finally, as an submitter of a lot of open/unconfirmed bugs it is not very easy to understand the owners priorities and when the bug will be fixed and merged to master/stable tag.

Agreed 100%. Lack of visibility into planning / resource allocation is
the worst. I sometimes have no choice but to "shed load" (review
requests etc). What I find important is to be honest about such cases,
and state "sorry, you've been dropped off my queue" reasonably quickly.
Leaving others hanging is one of the *worst* faces of open / distributed
development.

> I am happy to contribute effort to making a new process but want to understand if others are frustrated by this as well.

Oh yes.

> 
> 3. Discussions: I wanted to know if anyone has experience with user forums like https://www.discourse.org/.  Again the rust community uses this and it is a pretty nice interface for async communication that doesn't involve mail server and client configuration challenges, corporate policies, and the noise of email.

(You know my opinion on email ;))

Thanks
Laszlo

Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6

[Laszlo Ersek]

On 02/14/20 19:50, Rebecca Cran wrote:
> On 2/14/20 11:25 AM, Sean via Groups.Io wrote:
> 
>>
>> 3. Discussions: I wanted to know if anyone has experience with user
>> forums like https://www.discourse.org/.  Again the rust community uses
>> this and it is a pretty nice interface for async communication that
>> doesn't involve mail server and client configuration challenges,
>> corporate policies, and the noise of email.
> 
> 
> For real-time communications, I think many organizations now use Slack
> (https://slack.com).

In that case, the problem they have is not the tool (whatever it is),
but the fact that they need to communicate in real time. ;)

Sorry, couldn't resist!
Laszlo

Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6

[Sean]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Fri, Feb 14, 2020 at 02:14 PM, Laszlo Ersek wrote:

> 
> I think Bugzilla tickets are the best place to capture the focused
> analysis of a bug. I write a *lot* of text in Red Hat bugzillas (most of
> them are public, luckily!) -- I want to document my own "adventure" with
> the issue, even if most paths prove dead-ends in the end. How does that
> conflict with "forward progress"?

By this i mean during the meetings it is impossible to capture the conversation, be involved in the conversation, update the bugzilla, and still move fast enough.  In general I do believe putting detailed information in the bugzilla is great and not in conflict with forward progress but in the context of the meeting it is not practical.

[-- Attachment #2: Type: text/html, Size: 784 bytes --]

Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6

[Laszlo Ersek]

On 02/15/20 00:24, Sean via Groups.Io wrote:
> On Fri, Feb 14, 2020 at 02:14 PM, Laszlo Ersek wrote:
> 
>> 
>> I think Bugzilla tickets are the best place to capture the focused 
>> analysis of a bug. I write a *lot* of text in Red Hat bugzillas
>> (most of them are public, luckily!) -- I want to document my own
>> "adventure" with the issue, even if most paths prove dead-ends in
>> the end. How does that conflict with "forward progress"?
> 
> By this i mean during the meetings it is impossible to capture the
> conversation, be involved in the conversation, update the bugzilla,
> and still move fast enough.  In general I do believe putting detailed
> information in the bugzilla is great and not in conflict with forward
> progress but in the context of the meeting it is not practical.

Ah, agreed.

Thanks
Laszlo

Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6

[Soumya Guptha]

Hi Sean and Laszlo,
Great points. We should discuss with the community around the process and the governance. 
I will add these to our upcoming community meeting to brainstorm. 


Thanks,
Soumya


-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com> 
Sent: Friday, February 14, 2020 2:14 PM
To: devel@edk2.groups.io; sean.brogan@microsoft.com; Guptha, Soumya K <soumya.k.guptha@intel.com>
Subject: Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6

On 02/14/20 19:25, Sean via Groups.Io wrote:
> Soumya,
> I would like to add three things to community discussions especially around governance and process.
> 
> 1. RFC: The RFC process seems to get only minimal comments and a lot gets lost in the noise of the lists.  There isn't a good "final" state where all approved RFCs can be seen.  The process is entirely driven by the submitter and thus there is little consistency.   I wanted to highlight another project and how they handle this. https://github.com/rust-lang/rfcs ( https://github.com/rust-lang/rfcs ) As a casual observer it is very easy to review their RFCs (in flight and approved/rejected) as well as understand how to create and submit one if so desired.  The tooling is just git/github so it is familiar to the target audience and has a strong ability to track progress, show history, and be backed up like any code project.  They also leverage github issue tracker for pre rfc conversation and discussions.

I agree that RFCs get sorely little attention from the community.

... From my personal perspective, it's not because the RFCs are not visible -- I simply don't have time to even *understand* most RFCs for their merits. For example, I checked out Microsoft's VariablePolicy slides. The design seemed systematic and I appreciated that, it's just that I couldn't bring myself to make half-cooked comments (regardless of forum), because those wouldn't do justice to the topic, and I simply couldn't commit to a deeper involvement.

I can imagine that others appear to ignore several RFCs due to similar
(capacity) reasons.

> 2. Bugs/Features/Releases:  First the bug triage and scrub is not very 
> well attended.  I know it is hard to get a ww audience together on a 
> call

Personal angle again:
- synchronous communication hampers my throughput
- got quickly demotivated by perceiving significantly less effort from others

Bug triage is a thankless job.

> but i think part of the goal was to offer a public process and a place to learn/discuss.  Is there a better way that still meets those goals?  Secondly, the number of bugs that get discussed is pretty small and the list of open bugzillas are grower faster than the triage effort.  Third, the results are pretty minimal.  Usually a change in owner and a very short comment asking the owner to look at it is the result of the triage.  There is sometimes good conversation (assuming knowledgeable parties are in attendance) but this is impractical to capture into the bugzilla while still keeping forward progress.

Can you please clarify this suggested conflict (between capturing good technical discussion in the BZ tickets, and "forward progress")?

I think Bugzilla tickets are the best place to capture the focused analysis of a bug. I write a *lot* of text in Red Hat bugzillas (most of them are public, luckily!) -- I want to document my own "adventure" with the issue, even if most paths prove dead-ends in the end. How does that conflict with "forward progress"?

>   Finally, as an submitter of a lot of open/unconfirmed bugs it is not very easy to understand the owners priorities and when the bug will be fixed and merged to master/stable tag.

Agreed 100%. Lack of visibility into planning / resource allocation is the worst. I sometimes have no choice but to "shed load" (review requests etc). What I find important is to be honest about such cases, and state "sorry, you've been dropped off my queue" reasonably quickly.
Leaving others hanging is one of the *worst* faces of open / distributed development.

> I am happy to contribute effort to making a new process but want to understand if others are frustrated by this as well.

Oh yes.

> 
> 3. Discussions: I wanted to know if anyone has experience with user forums like https://www.discourse.org/.  Again the rust community uses this and it is a pretty nice interface for async communication that doesn't involve mail server and client configuration challenges, corporate policies, and the noise of email.

(You know my opinion on email ;))

Thanks
Laszlo