As a casual contributor, for me the biggest complaint I have is how busy the mailing list gets. I don't think a new 'announce' list is what's needed, perhaps a 'reviews' or 'discussion' list to split out discussions (from anyone) from day-to-day patches? Also, I'd be anxious about jumping to a new service like most open source developers understand plain email, and personally I'd like that to stay. For example FreeBSD set up web forums, but most contributors continue to use the existing mailman based lists, and I suspect tend to forget the web interface exists.

One thing I feel that's missing from the current Github-based infrastructure of the web site and wiki is that as far as I know there's no API documentation built regularly, or automated builds etc. I'm hosting the API documentation at e.g. . Also, one thing a review system like Gerrit, Github, Phabricator, Review Board etc. would give us is the ability to run tests (lint, build/run OVMF etc.) against patches and have it comment on the review about its status to give committers more confidence in it.


Rebecca Cran

On 2/14/19 12:07 PM, Jeremiah Cox via edk2-devel wrote:
Hi Ard,
My apologies as no insult was intended.  The suggestion is that, similar to 
today, folks encountering difficulties with our systems could reach out to the 
TianoCore discussion venue (our mailing list or, and our friendly 
community members (we have many) will surely assist them.

You are correct that my focus is not casual contributors, rather I want to 
encourage a large number of UEFI developers who are currently closed to stop 
their fork-modify-ship model, which is inefficient to service, go open to share 
their learnings, get current, stay current, upstream their changes (where it 
makes sense to the community), but not throw garbage over the wall.   I think 
there is some value in this endeavor.

Kind Regards,

From: Ard Biesheuvel <>
Sent: Friday, February 8, 2019 5:58 AM
To: Jeremiah Cox
Cc: stephano;; Kinney, Michael D; Laszlo Ersek
Subject: Re: [edk2] [edk2-announce] Community Meeting Minutes

On Thu, 7 Feb 2019 at 18:52, Jeremiah Cox via edk2-devel
<> wrote:
Apologies on the late reply, I was on vacation for several weeks and just got 
back to this.

Regarding "Patch Review System Evaluation", on the call, I disagreed with your 
conclusion, but that note is not captured below.  My reading of the email and call discussions, I 
did not hear our community reject GitHub, rather observations that it was not "perfect", 
that it does not transparently interact with folks who prefer mailing list patch systems, but it 
would be acceptable to try.  On the call you mentioned a second justification for staying with the 
mailing list system, that GitHub (really all modern patch management systems) exclude folks who 
have limited internet connectivity.  I hypothesize that this theoretical group of Tianocore 
contributors would be a very small group of folks.  Should our community optimize our systems for a 
very small, theoretical group, penalizing the overwhelming majority?  I would propose that we try a 
modern patch management system, GitHub had the best reviews in my reading, and folks with limited 
internet connectivity find a friend to act as a go between translating their email diffs into 
GitHub PRs.
I find this unnecessarily condescending. Finding a friend, seriously?

Very serious concerns have been raised about the lack of transparency
with the various systems, and the fact that I am able to consult my
own local copy of the entire review history, including all email
exchanges is a very important aspect of the current model to me, as
opposed to GitHub deciding what is important enough to keep and what
is not. In an open source project, the code base is *not* the HEAD
commit, it is the entire repository, including history, and logged
email threads with technical discussions, since they are usually not
captured in other ways.

The push to GitHub is being sold to us as a way to attract more
contributors, but it seems to me (and I have stated this multiple
times) that the mailing list is not the steep part of the learning
curve when contributing to TianoCore. So is this really about getting
outsiders to contribute to Tianocore? Or is it about reducing the
impedance mismatch with what internal teams at MicroSoft (and Intel?)
are doing, which probably already went through the learning curve when
it comes to other aspects of Tianocore.

 From a high level, it might seem that using a mailing list is the
impediment here. But in reality, contributing to open source in
general is not about whether you use GitHub or a mailing list to throw
your stuff over the fence. It is about collaborating with the
community to find common ground between the various sometimes
conflicting interests, and permitting your engineers to engage with
the community.

Tianocore has always been a rather peculiar open source project, since
it wasn't more than just that, i.e., openly available source code.
This has been changing for the better during the time I have been
involved, and we have worked very hard with the Intel firmware team
and other contributors to collaborate better on the mailing list.

To summarize my concern here: it seems that this push is not about
making it easier for contributors that already know how to do open
source collaboration to contribute to Tianocore, it is about making it
easier for currently closed code to be contributed to Tianocore by
teams who have no prior experience with open source.

Apologies if I have the wrong end of the stick here. If not, why don't
we consult a few casual contributors (which should be easy to find on
the mailing list) and ask them what their biggest issues were with
contributing to Tianocore?

-----Original Message-----
From: edk2-devel <> On Behalf Of stephano
Sent: Friday, January 11, 2019 11:27 AM
Cc: Kinney, Michael D <>; Laszlo Ersek 
Subject: [edk2] [edk2-announce] Community Meeting Minutes

An HTML version is available here:;;sdata=EVNgiM90x5nka9boa%2BVsCPVEJjib%2BfcDpQFLJ5m27cs%3D&amp;reserved=0

Community Updates
Several conferences are coming up that we will be attending.

Stephano will be giving a talk with Alexander Graf (SUSE) on UEFI usage on the 
UP Squared board and Beagle Bone Black.

More info on FOSDEM here:;;sdata=1weJ37WVTOJP4Et%2BgUJqF2KGIfV5g6IlGXEV8n0Lelw%3D&amp;reserved=0

Info on the talk here:;;sdata=BHkTSCSGQ71rh1G2zr%2FTFtxnzvUXK47vHES7hs0Cvh4%3D&amp;reserved=0

Open Compute Project Global Summit;;sdata=8Wer0jAgTX2pMeHddxcNdCXmAblGy5pVTfsotl6n1xE%3D&amp;reserved=0

No TianoCore talks were accepted for this event, however Stephano will be 
talking about CHIPSEC.;;sdata=l3DULTiWsTfbxEoupZ1EbM6SJ2bsHFqK1rVIdl6oolY%3D&amp;reserved=0

Other Upcoming Conferences
Linuxfest NW
Redhat Summit

Stephano is working with some folks from the Open Source Technology Center at Intel 
regarding their desire to get Rust ported to EDK2. While there are many proof of concepts 
out there, the first step for adoption would be to integrate the Rust infrastructure into 
our build system, and create a simple "hello world" app. The goal would be to 
provide a modern language with better memory safety for writing modules and drivers. Our 
hope is that the availability of this language would encourage outside contribution and 
support from a vibrant and well established open source community.

Github Discussions Evaluation,, Microsoft Teams
During our December community meeting, we talked about trying out "GitHub 
Discussions" as a basis for communication that might be better than our current 
mailing list situation. The main issues with the mailing list today are:

1. Attachments are not allowed.
2. Email addresses cannot be "white listed" (If you are not subscribed your 
emails are simply discarded by the server).

In order to save us some time, Stephano reviewed GitHub discussions using 3 
GitHub user accounts, and found the following shortcomings:

1. No support for uploading documents, only images 2. No way to archive 
discussions outside GitHub[1] 3. Any comment can be edited by any member 4. 
Discussions are not threaded

[1] Email notification archiving is possible, but this means we'd have to keep 
a mailing list log of our conversations. At that point, why not just use email?

That last one is particularly difficult to work around. Every comment is added to the 
bottom of the list. If some small group of developers (out of many) start having a “sub 
discussion”, their replies will not be separate from the main thread. There’s no way to 
distinguish and visually “collapse” a sub thread, so one is forced to view the discussion 
as a whole. It would seem that the "discussion feature" was intended for small, 
single threaded discussions. This will not work for larger complex system design 

Also, the ability to edit comments is perplexing. Any member can edit any comment, and delete any 
of their comments or edits. No email notifications are provided for these actions, so there may be 
no document trail for parts of the conversation. This system seems quite inadequate for serious 
development discussions and is clearly meant for a more "chat" style of communication on 
smaller teams. Comments and questions regarding "GitHub Discussions" are still welcomed, 
but Stephano recommends we move forward with trying out different systems with more robust feature 

It was agreed that we will evaluate next to see if that is a better fit for our needs. 
Stephano will setup accounts as needed and do some preliminary testing. If that goes well he will 
initiate discussions on "Line Endings" as well as "Use of C Standard Types".

Microsoft Teams was also brought up as a possible solution. If fails to provide 
a good platform for us, we will look into Teams. The main barrier to entry there may be 
the cost. We have found that many of the software options we have been evaluating have 
this cost barrier to entry. We need to decide if this is truly a "no-go" issue 
for using software as a community. If TianoCore was an organization that had non-profit 
status, it might be easier for us to get non-profit discounts on software like this. 
Stephano will bring this up at the Steward's Meeting next week.

Patch Review System Evaluation
After evaluating Github, Gitlab, and Phabricator, we will be remaining with the mailing 
list for now. Github did prove a possible "2nd runner up" (albeit distant). 
Also, Stephano / Nate from Intel will be reviewing Gerrit use with a report being sent 
back to the community sometime next week.

Community CI Environment
Azure DevOps, Cirrus CI, Jenkins, Avacado We will begin evaluation of possible 
community test frameworks. This again brings up the question of how we would 
fund such an effort, and Stephano will bring this up at the Steward's meeting. 
It is important to remember that our supported environments are Linux, Windows, 
and macOS.
We have compilers that are considered "supported" and those combinations should 
have proper coverage. Also, we do not want to use multiple CI environments, so the 
solution we choose should support all use cases.
There are several CI options that are "Free for open source" but they limit the 
size / number of CI agents, with pricing tiers for larger sized builds. The cost of a CI 
infrastructure will be dependent on the number of patches we need to send through the 
service, and what kind of response is required. Stephano will work with Philippe on 
Avacado, the folks at MS will evaluate possible use of Azure DevOps (again, possibly 
limited by the fact that we are not a non-profit), and volunteers are still required to 
test Cirrus and Jenkins.

Public Design / Bug Scrub Meetings
We'd like to get public meetings started in February for design overviews and 
bug scrubs. Stephano will be working with Ray to set these up. The hope is that 
we will have 1 meeting per month to start for bug scrubs. Design meetings will 
be dependent on how many design ideas have been submitted. The design meetings 
could also be used to discuss RFC's from the mailing list.

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

edk2-devel mailing list;;sdata=%2ByLNjAyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserved=0
edk2-devel mailing list;;sdata=%2ByLNjAyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserved=0
edk2-devel mailing list

edk2-devel mailing list

Reply via email to