From: stephano <stephano.cetola@linux.intel.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Laszlo Ersek <lersek@redhat.com>, Andrew Fish <afish@apple.com>
Subject: [edk2-announce] Community Meeting Minutes
Date: Fri, 11 Jan 2019 11:26:30 -0800 [thread overview]
Message-ID: <bc0dcd1a-e63e-488e-11dd-ac53109deea0@linux.intel.com> (raw)
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
next reply other threads:[~2019-01-11 19:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 19:26 stephano [this message]
2019-01-13 3:59 ` [edk2-announce] Community Meeting Minutes 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc0dcd1a-e63e-488e-11dd-ac53109deea0@linux.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox