TianoCore Community Meeting Minutes - March

["Soumya Guptha" <soumya.k.guptha@intel.com>]

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

TianoCore Community Meeting Minutes
March 5, 2020

Stable Tag Updates:

1.       Edk2 stable tag 202002 has been released: https://github.com/tianocore/edk2/releases/tag/edk2-stable202002

2.       Edk2 stable tag 202005 feature planning has started.

*       Features are listed in: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
Community Action: Please send if any feature requests that needs to be added to the upcoming stable tag release.
Opens:

1.      Sean requested a few features (variable policy, TLS 1.3 etc.) for stable tag Q2 release. Sean will follow up with Liming on those features to get them added to Q2 stable tag.


2.      Kevin - Need a fix in EDK2. Insyde engineers don't know where to start. Documentation is stale or assumes that you understand the open source project.

*       Action: We discussed this issue. Kevin to follow the link  - https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process , this should provide some guidance to the engineers on how to make a fix in EDK2.


3.      Discussion around Bugzilla - Liming to explore adding more detailed information on bugzilla wiki page


TianoCore Bug Triage - APAC / NAMO Meeting time:

*       Scheduled currently from 9:00 ~ 9:30 AM PRC time. Even after the US daylight saving during March, plan is to keep this meeting from 9:00~9:30AM PRC time. This time is working well and close to TianoCore Design Meeting, developers can plan their time and attend these two meetings together.

Community consensus received on the timeslot.

Events:
SPRING 2020 UEFI PLUGFEST<https://uefi.org/Spring2020Plugfest> has been postponed due to the Coronavirus situation. More details are published here - https://uefi.org/events/upcoming

Community issues that were brought up last month on the governance and the 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 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 a 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.

Intel Response: We are evaluating the possibility of using git hub for the code review process. Expect RFCs in the month of March.

Regards,
Soumya

Soumya Guptha
Open Source Program Manager, Intel Corporation


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