Hey Jeremiah,
My apologies if I was not clear in the minutes. We are not rejecting
Github, but rather taking time to evaluate how we can supplement
Github's features to emulate our current patch review requirements. We
do not want to rush into change and risk losing data or causing
frustration for those developers currently contributing on a regular basis.
I am currently working off this list of issues that Laszlo brought up:
https://lists.01.org/pipermail/edk2-devel/2018-December/033509.html
To be clear, Laszlo is not the only package maintainer that has voiced
these concerns. The longevity of pull request branches and the fact that
email notifications lack context are top on my list. There are several
ways to overcome these obstacles, and finding the best solution will
ensure that if we transition to Github, that transition is successful.
The ability to allow developers to work offline (or with intermittent
connections) is an important aspect as well. We cannot practice
exclusionary or ostracizing behaviors if we expect to grow and maintain
a community. I cannot imagine that Github has become as popular as it is
if it cannot facilitate ease of offline use.
Hope that helps, and again, sorry if i was unclear on this.
Cheers,
Stephano
On 2/7/2019 9:52 AM, Jeremiah Cox 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. Lets give it a try and see if the pros outweigh the cons.
Thank you,
Jeremiah
-----Original Message-----
From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of stephano
Sent: Friday, January 11, 2019 11:27 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek
<ler...@redhat.com>
Subject: [edk2] [edk2-announce] Community Meeting Minutes
An HTML version is available here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-2019-01.html&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=QuHaAW3%2Fw3lPV8JnHskquCRJ6VlVCDNV2rptymjvCFY%3D&reserved=0
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffosdem.org%2F2019%2F&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=rECfPlMrOzcpi5GSCBEHUFmycKMA7gshN82bAPcXw0I%3D&reserved=0
Info on the talk here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffosdem.org%2F2019%2Fschedule%2Fevent%2Fuefi_boot_for_mere_mortals%2F&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=smcg%2B0hTO8oI3yVThCcnB1j8pRWA37XTLrqeNeE8vos%3D&reserved=0
Open Compute Project Global Summit
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-summit&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=gZpss9dmcJ7MqREcz%2FomaI8Un6157gM15%2FHTmOoOfyE%3D&reserved=0
No TianoCore talks were accepted for this event, however Stephano will be
talking about CHIPSEC.
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsched.co%2FJinT&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=2PGlE%2Faop%2Bw5A3gnhOJCO4S09FuLc4lc%2FNbIMtcdLog%3D&reserved=0
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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=5pqGQCWQvCSsT17rw%2BhSMtgJEHsdPZ8vvZ%2F1yFniPkM%3D&reserved=0
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
