public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* [edk2-announce] Community Meeting Minutes
@ 2019-01-11 19:26 stephano
  2019-01-13  3:59 ` Rebecca Cran
  2019-02-07 17:52 ` Jeremiah Cox
  0 siblings, 2 replies; 26+ messages in thread
From: stephano @ 2019-01-11 19:26 UTC (permalink / raw)
  To: edk2-devel@lists.01.org
  Cc: Kinney, Michael D, Leif Lindholm, Laszlo Ersek, Andrew Fish

An HTML version is available here:
https://www.tianocore.org/minutes/Community-2019-01.html

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

FOSDEM 2019
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:
https://fosdem.org/2019/

Info on the talk here:
https://fosdem.org/2019/schedule/event/uefi_boot_for_mere_mortals/

Open Compute Project Global Summit
https://www.opencompute.org/summit/global-summit

No TianoCore talks were accepted for this event, however Stephano will 
be talking about CHIPSEC.
https://sched.co/JinT

Other Upcoming Conferences
Linuxfest NW
PyCon
Redhat Summit
RustConf

Rust
----
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, Groups.io, 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 discussions.

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

It was agreed that we will evaluate Groups.io 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 Groups.io 
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



^ permalink raw reply	[flat|nested] 26+ messages in thread
* [edk2-announce] Community Meeting Minutes
@ 2019-02-20  6:23 stephano
  2019-02-20  6:45 ` stephano
  2019-02-20  7:49 ` Rebecca Cran
  0 siblings, 2 replies; 26+ messages in thread
From: stephano @ 2019-02-20  6:23 UTC (permalink / raw)
  To: edk2-devel@lists.01.org

An HTML version is available here:
https://www.tianocore.org/minutes/Community-2019-02.html

Github Pull Requests
---------------------
We are still considering Github as a possible platform for patch review. 
There are two issues we'd like to overcome:

1. comprehensive email notifications or backup/archival functionality
2. workflow for users that do not have a consistent internet connection

The notification issue degrades our current ability to archive the 
history of a patch review. Github notifications do not provide:

1. the subject line of the patch
2. trailing code context of comments (code that comes AFTER the comment)
3. the commit message

In this way, it is hard to avoid losing the meaning of the pull request 
conversation if we were to move to a different system some day. The 
longevity of PR branches is also a concern, and a workaround would need 
to be found and maintained. We need to be sure that PR branches can be 
easily archived so that if a Github user deletes their account, even if 
their PR was rejected, the code would be available.

Jeremiah and I are both looking for work around to these issues, 
hopefully without having to maintain more code. See here for details on 
Laszlo's thorough Github evaluation:

https://lists.01.org/pipermail/edk2-devel/2018-December/033509.html

To be clear, these hurtles do not *have to be* overcome. They were 
brought up by several maintainers and community members. They are simply 
barriers that we want to discuss fully before committing to a 
transition. It is impossible to "change our mind" on this transition 
without some loss of data, so best we be sure before we switch.

Working in a community means providing consistent messaging, clear 
expectations, and the understanding that each member is valuable. 
Working in the open means moderating, evaluating, and distilling input 
from community members and companies without bias or prejudice. I take 
this transition seriously and do not plan to rush it.

Gerrit Code Review
---------------------
Gerrit code review is viable platform, but Intel's implementation of the 
'repo' tool is still working on being open sourced. Also, there would be 
a lot of work that would go into implementing a proper Gerrit solution. 
If someone would like to volunteer to carry this out, please feel free 
to contact me, but I'm going to postpone this for the moment as my 
schedule is rather full.

Groups.io
---------------------
Laszlo and I will evaluate Groups.io, however initial impressions is 
that this will work as a communication platform going forward. We'd like 
to use this for design discussions and as a replacement for our current 
mailing list as 01.org does not allow attachments or whistling. Also, 
Groups.io allows for online search of the list, chats, and uploads which 
is much easier for some than searching through emails. Assuming this is 
successful, I will work with 01.org to archive all (if possible) of the 
edk2-devel mailing list into groups.io for a (mostly) seamless 
transition. I will see how long 01.org is willing to store archives, and 
will notify the community of how long that archive will be available.

Community Bug Triage
---------------------
Community bug triage meetings will occur every two weeks, and we will 
have 2 meetings to accommodate both sets of timezones. See here for details:

https://www.tianocore.org/bug-triage/

I will be working to develop bugzilla reports and researching possible 
platforms that we could add to a community CI. Maintaining these 
platforms would be a great way to add to the list of community bugs and 
encourage open development.

Community Design
---------------------
We will be starting the community design meetings in March and holding 
them every 2 weeks. If we find that there are enough submissions we can 
meet every week. I will hold two meetings, much like the community 
meetings. Any submission will be discussed in both meeting and notes 
sent out in the meeting minutes. Discussion can then continue on the 
mailing list. I will send out an RFC for folks to submit possible topics 
the day before each meeting.

Rust in EDK II Exploration Notes
------------------------------------------
I have been working with the Rust community, as well as members of 
Intel's Firmware Security teams, to explore the benefits of using Rust 
in EDK II. For those of you who have never heard of Rust, please take 
some time to look into it:

https://en.wikipedia.org/wiki/Rust_(programming_language)

Here is a brief overview of the pros/cons:

Benefits of Rust
Rust is a modern language with features like counted buffers and 
strings. It can call C code and be called by C code. It requires no 
calls to "free", and does so without garbage collection by statically 
inserting calls to "free" for you. Rust types keep track of which 
structs own which memory chunks so that developers do not have to keep 
track of ownership of struct memory. Rust includes a lot of 
functionality not found in C. These features include Unicode support, an 
ecosystem library, structural types, and matching (it is very easy to 
wrap types as a "SUCCESS" or "FAILURE WITH ERROR CODE"). Rust has no 
NULL pointers as that concept has its own type, which makes for cleaner 
semantics. It has a robust built in macro system. For example, when you 
get a compilation error in code calling a macro, the compiler will be 
able to show you where in the macro the failure occurred.

Drawbacks of Rust
Rust is a younger language, though there are many examples of where it 
has been used in production. As such, many features one might take for 
granted in C still do not exist in Rust, or are newly added. For 
example, variadic functions (varargs) were just recently added. There 
are other corner cases of "things you can do in C" that still need to be 
added. Rust does have a great package management system (called cargo - 
crates are packages), but in a system like EDK2, we will want to limit 
those outside dependencies. Sub-command cargo-vendor is a tool where you 
can pin package versions and update them only as needed.

TianoCore in the News
---------------------
Here's my presentation from FOSDEM:

https://fosdem.org/2019/schedule/event/uefi_boot_for_mere_mortals/

I collaborated with Alexander Graf from SUSE. I'll be giving this talk 
again at LinuxFest Northwest (http://linuxfestnorthwest.org).

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


^ permalink raw reply	[flat|nested] 26+ messages in thread
end of thread, other threads:[~2019-02-22 11:52 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-11 19:26 [edk2-announce] Community Meeting Minutes stephano
2019-01-13  3:59 ` Rebecca Cran
2019-01-14  9:28   ` Laszlo Ersek
2019-01-14 17:06   ` stephano
2019-02-07 17:52 ` Jeremiah Cox
2019-02-07 18:30   ` stephano
2019-02-08  6:41     ` Rebecca Cran
2019-02-08  9:01       ` Laszlo Ersek
2019-02-08 17:33         ` Rebecca Cran
2019-02-08 17:52           ` Andrew Fish
2019-02-22 11:52             ` Rebecca Cran
2019-02-08 20:33           ` Laszlo Ersek
2019-02-08 13:58   ` Ard Biesheuvel
2019-02-14 19:07     ` Jeremiah Cox
2019-02-14 20:27       ` Rebecca Cran
2019-02-14 22:13         ` Kinney, Michael D
2019-02-15  2:56           ` Rebecca Cran
2019-02-15 14:30             ` Laszlo Ersek
2019-02-15 17:55             ` stephano
2019-02-15  8:43       ` Ard Biesheuvel
2019-02-15 14:23         ` Laszlo Ersek
2019-02-15 19:54           ` Felix Polyudov
2019-02-15 22:53             ` Laszlo Ersek
  -- strict thread matches above, loose matches on Subject: below --
2019-02-20  6:23 stephano
2019-02-20  6:45 ` stephano
2019-02-20  7:49 ` Rebecca Cran

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox