TianoCore Community Meeting Minutes

[stephano <stephano.cetola@linux.intel.com>]

Thank you all for a great set of meetings!

This is an overview of the topics discussed and the tasks that were 
assigned. Please feel free to send me any questions or comments.

Licensing
---------
Licensing was discussed and no questions or comments came up. Please 
feel free to contact me directly if you would like more info.

Community Meetings
------------------
Community meetings will be held regularly. We will plan public bug 
scrubs and design meetings. Meeting formats will use zoom and be held 2 
times per day to accommodate all time zones. Invites will be posted to 
the mailing list and the wiki. Since the mailing list does not allow 
attachments, I will work on getting an "add to calendar" link attached 
to the wiki page.

I will send out a poll to see if the community would be interested in a 
Slack channel. I'm happy to admin it if there is interest.

I will also be setting up a specific meeting, probably next month, to 
discuss general code and commit message standards.


Patch Workflow Improvement
--------------------------
We would like to find a more modern, user friendly patch workflow that 
fits (as best as it can) most company's workflow. It is recommended that 
the community familiarize themselves with some of the options that are 
out there so that we can pose useful questions / comments at the next 
meeting. Please be sure to research up-to-date information and not rely 
on old info. Options and tools discussed included:
-Github
-Gitlab
-Phabricator
-Gerrit

The was a concern raised over potential lock-in to Github's, 
specifically in regards to history retention. Several Github users 
brought up that this shouldn't be an issue. Shawn mentioned some 
benefits to stock Github such as it is always up to date, it includes 
APIs to extract data, pull requests lend themselves to simple(r) 
automation, and it has a much more modern web UI than Gerrit.

Several community members including Marcin and Rebecca have used 
Phabricator and can recommend it. Intel has used Gerrit internally and 
can recommend its use.

No one voiced any issues with Bugzilla and several from the community 
thought that we should continue to use it.

Improvements to the Build Process
--------------------------------
We would like to gather a list of concrete specific proposals. Nate 
mentioned that there will always be some specialized tooling because of 
the nature of BIOS. Shawn mentioned that we need to keep in mind that 
making development easier for current developers should be a priority 
over making the processes easier for newcomers. I will send out emails 
asking for specific feedback on some of these topics:

-Which toolchains are being used, which are validated, and which are 
known to create reproducible builds.
-When toolchains are known to be orphaned, should they be archived or 
simply removed.
-Could we add some kconfig-like tool that allows introspection into what 
type of builds are available.
-How can we better track the code quality of BaseTools and the current 
build system on the whole. Should we add a "requires documentation 
change" flag to BZ so that it will be easier to compile a list of 
required doc changes.

Changing to LF instead of CRLF
------------------------------
It was agreed that this is a good idea but that we should create a test 
repo to verify this change before implementing it. It was noted that 
this will cause some overhead with tasks like git blame, however the 
benefits outweigh the costs.

Switching to Standard C Types
-----------------------------
Both Shawn and Nate mentioned that the current system has been in place 
for a long time and some people prefer the current setup. I can start an 
email discussion around this issue specifically if anyone feels strongly 
that we should be using standard types.

Using Git Submodules (like we do with OpenSSL)
--------------------
Many in the group liked this idea. I will engage with the communities to 
gauge their interest in taking patches or helping with our integration 
of their software.

Public CI
---------
This subject was not discussed at length but there seems to be quite a 
bit of community interest. We will discuss this more in the next 
meeting. Please familiarize yourself with some possible solutions, with 
a focus on supporting Windows + Linux + Mac. Some possible solutions 
include:

https://azure.microsoft.com/en-us/blog/introducing-azure-devops/
https://cirrus-ci.org/

Mike has tried out Cirrus with some success. Some positive points to 
Cirrus include:
-Build time of ~ 7 Minutes (clone edk2, apt-get all dependent tools, 
build BaseTools, and build 3 versions of OVMF)
-Caching of VM contents so reduce build times of subsequent builds
-We could use platforms like OVMF to boot FW and provide test results 
from tools like MicroPythonTestFramework
-Cirrus includes integration with docker


Cheers,
Stephano

Stephano Cetola
TianoCore Community Manager
stephano.cetola@linux.intel.com