Re: TianoCore Community Meeting Minutes

[Leif Lindholm <leif.lindholm@linaro.org>]

Hi Stephano,

Thanks for pulling this together.
Some comments below.

On Thu, Oct 11, 2018 at 10:43:57AM -0700, stephano wrote:
> 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.

So I didn't comment on the call (which I dialled in to, using a
phone, because that was the only thing that wasn't going to delay me
10 minutes), but I would prefer a conferencing system that does not require
binary downloads to participate in.

I know at least one organisation that would be prevented from using it
until they had explicit approval (which could take a while), and it
puts me in the position of having to keep a spare x86 machine on my
desktop in order to participate.

Solutions I know would work in this scenario (i.e. work without
plugins or downloads in any modern browser) are:
- google hangouts (requires accounts, not ideal for China)
- Skype (not SFB though, only plain old Skype)
- Bluejeans (requires organiser account)

Sure, I could attend via the Android app for zoom, but it would make
it tedious to paste links to/from chat and put me on a tiny screen.

> 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.

Hopefully they said more than that.
What does "shouldn't be an issue" mean.
Were these users from multiple organisations?

> Shawn mentioned some benefits to stock Github such as
> it is always up to date, it includes APIs to extract data, pull
> requests

Since we are discussing multiple different development systems, can we
try to be a bit more explicit? This is referring to github's web-based
branch-based ticketing system, yes?

I know language drift and all, but
https://www.kernel.org/doc/html/latest/maintainer/pull-requests.html
is what pull request means to at least 3 participants in this conversation.

> lend themselves to simple(r) automation, and it has a much more modern web
> UI than Gerrit.

It seems somewhat less than ideal to me that all of the github
proponents were on the opposite call to me and Laszlo (and Ard). Were
any of them Asia-based or could we try to get them on the call with
Europe next time? I'm sure me and Laszlo could be somewhat more
accommodating than your 7AM, but we're not going to stay up for a 3/4AM
meeting about source control.

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

I don't think we had anyone from ARM on either of the calls, but I
know they use gerrit internally.

For those who weren't on the call I was on, I am _not_ a fan of gerrit
- but if the deciding factor (as suggested above) is to best align
with the internal processes of contributing organisations, then
gerrit wins hands down.

> 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.

Well, in our call this was more about the ability to enable larger
groups of functionality without having to explicitly list every single
module included.

> -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.

Could we also have a thread on someting that you sort of mention in
the text, but not the bullet points?:
- Suggestions for improvements to BaseTools.

> 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.

So, I don't think we made it this far down the agenda on the US-EU
call.

One way would be to simply explicitly permit it, possibly with the
constraint that every module needs to pick one and stick with it,
unless people object.

I think we'll want to discuss this in a US-EU call as well.

> Using Git Submodules (like we do with OpenSSL)
> --------------------

We didn't make it here either. What would we use it _for_?
I think the openssl case makes a lot of sense, but what else?

> 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.

I think we do need to discuss it on the US-EU call as well before we
do anything else.

> 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

I wouldn't have anything to add on this topic in a US-EU call, but
thanks for the links.

Regards,

Leif