From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.93; helo=mga11.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 60F9F208AE2B2 for ; Thu, 14 Feb 2019 14:13:22 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2019 14:13:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,370,1544515200"; d="scan'208";a="146966378" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by fmsmga001.fm.intel.com with ESMTP; 14 Feb 2019 14:13:21 -0800 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Feb 2019 14:13:21 -0800 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.97]) by ORSMSX114.amr.corp.intel.com ([169.254.8.37]) with mapi id 14.03.0415.000; Thu, 14 Feb 2019 14:13:21 -0800 From: "Kinney, Michael D" To: Rebecca Cran , Jeremiah Cox , Ard Biesheuvel , "edk2-devel@lists.01.org" , "Kinney, Michael D" CC: Laszlo Ersek Thread-Topic: [edk2] [edk2-announce] Community Meeting Minutes Thread-Index: AQHUqeOPNMbgHcE4r0GnniZT9diXZqXVTgwAgAFRKYCACcQ9gIAAFm8A//+XSIA= Date: Thu, 14 Feb 2019 22:13:20 +0000 Message-ID: References: <8c173279-5566-4b5f-8bbb-46b5a18b4797@bluestop.org> In-Reply-To: <8c173279-5566-4b5f-8bbb-46b5a18b4797@bluestop.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.138] MIME-Version: 1.0 Subject: Re: [edk2-announce] Community Meeting Minutes X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 22:13:22 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rebecca, You can review the groups.io features. I think what you=20 want is available. Stephano has also setup an edk2 area in groups.io for community member to try out. https://groups.io/static/help#features There are a number of CI services that are integrated with GitHub. https://github.com/marketplace/category/continuous-integration There is work to be done to enable one of these CI services for edk2. Stephano has a community task to evaluate and select a CI service. Best regards, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel- > bounces@lists.01.org] On Behalf Of Rebecca Cran via > edk2-devel > Sent: Thursday, February 14, 2019 12:28 PM > To: Jeremiah Cox ; Ard > Biesheuvel > Cc: Kinney, Michael D ; > edk2-devel@lists.01.org; Laszlo Ersek > > Subject: Re: [edk2] [edk2-announce] Community Meeting > Minutes >=20 > 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 groups.io: 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. >=20 >=20 > 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. > https://code.bluestop.org/edk2/docs/master/ . 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. >=20 >=20 > -- >=20 > Rebecca Cran >=20 >=20 > 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 groups.io), 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, > > Jeremiah > > > > ________________________________ > > From: Ard Biesheuvel > > Sent: Friday, February 8, 2019 5:58 AM > > To: Jeremiah Cox > > Cc: stephano; edk2-devel@lists.01.org; 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 > >> To: edk2-devel@lists.01.org > >> Cc: Kinney, Michael D ; > Laszlo Ersek > >> Subject: [edk2] [edk2-announce] Community Meeting > Minutes > >> > >> An HTML version is available here: > >> > https://nam06.safelinks.protection.outlook.com/?url=3Dhtt > ps%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity- > 2019- > 01.html&data=3D02%7C01%7Cjerecox%40microsoft.com%7Ce1 > 986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d > 7cd011db47%7C1%7C0%7C636852311581785508&sdata=3DEVNgi > M90x5nka9boa%2BVsCPVEJjib%2BfcDpQFLJ5m27cs%3D&reser > ved=3D0 > >> > >> 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=3Dhtt > ps%3A%2F%2Ffosdem.org%2F2019%2F&data=3D02%7C01%7Cjere > cox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368523115 > 81795501&sdata=3D1weJ37WVTOJP4Et%2BgUJqF2KGIfV5g6IlGX > EV8n0Lelw%3D&reserved=3D0 > >> > >> Info on the talk here: > >> > https://nam06.safelinks.protection.outlook.com/?url=3Dhtt > ps%3A%2F%2Ffosdem.org%2F2019%2Fschedule%2Fevent%2Fuefi_ > boot_for_mere_mortals%2F&data=3D02%7C01%7Cjerecox%40m > icrosoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f98 > 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C63685231158179550 > 1&sdata=3DBHkTSCSGQ71rh1G2zr%2FTFtxnzvUXK47vHES7hs0Cv > h4%3D&reserved=3D0 > >> > >> Open Compute Project Global Summit > >> > https://nam06.safelinks.protection.outlook.com/?url=3Dhtt > ps%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal- > summit&data=3D02%7C01%7Cjerecox%40microsoft.com%7Ce19 > 86594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7 > cd011db47%7C1%7C0%7C636852311581795501&sdata=3D8Wer0j > AgTX2pMeHddxcNdCXmAblGy5pVTfsotl6n1xE%3D&reserved=3D0 > >> > >> No TianoCore talks were accepted for this event, > however Stephano will be talking about CHIPSEC. > >> > https://nam06.safelinks.protection.outlook.com/?url=3Dhtt > ps%3A%2F%2Fsched.co%2FJinT&data=3D02%7C01%7Cjerecox%4 > 0microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f > 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795 > 501&sdata=3Dl3DULTiWsTfbxEoupZ1EbM6SJ2bsHFqK1rVIdl6oo > lY%3D&reserved=3D0 > >> > >> 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=3Dhtt > ps%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2- > devel&data=3D02%7C01%7Cjerecox%40microsoft.com%7Ce198 > 6594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7c > d011db47%7C1%7C0%7C636852311581795501&sdata=3D%2ByLNj > AyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&reserve > d=3D0 > >> _______________________________________________ > >> edk2-devel mailing list > >> edk2-devel@lists.01.org > >> > https://nam06.safelinks.protection.outlook.com/?url=3Dhtt > ps%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2- > devel&data=3D02%7C01%7Cjerecox%40microsoft.com%7Ce198 > 6594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7c > d011db47%7C1%7C0%7C636852311581795501&sdata=3D%2ByLNj > AyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&reserve > d=3D0 > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel