From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=96.73.9.1; helo=muon.bluestop.org; envelope-from=rebecca@bluestop.org; receiver=edk2-devel@lists.01.org Received: from muon.bluestop.org (muon.bluestop.org [96.73.9.1]) (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 A72F620886FF0 for ; Thu, 14 Feb 2019 12:28:00 -0800 (PST) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 41B2EFEB3; Thu, 14 Feb 2019 13:28:55 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluestop.org; s=mail; t=1550176135; bh=DcIiasm4dW6AYE/K6W/uSMBi2CxqbPp0Poi+UMP0I1k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BmKxyIG/VAHRL3XEPnu8jZB9B6hwrammQ4cegAEYcKsAO+ZCmUhuMn7iLeeay5DB2 VRkgFz3nkv6WlWrk7JRM+J5h91m5lJ9x2GYSf8/ZO21Be3Qc8CAHRjQEe7jgXAX37v LqUFNvNi+HGvZX+YSKLVZLlcT4RSG4uHZPjC+ZmU= Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BDuSW-wQGkye; Thu, 14 Feb 2019 13:28:54 -0700 (MST) Received: from macbex.int.bluestop.org (gw.bluestop.org [96.73.9.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Thu, 14 Feb 2019 13:28:54 -0700 (MST) To: Jeremiah Cox , Ard Biesheuvel Cc: "Kinney, Michael D" , "edk2-devel@lists.01.org" , Laszlo Ersek References: From: Rebecca Cran Message-ID: <8c173279-5566-4b5f-8bbb-46b5a18b4797@bluestop.org> Date: Thu, 14 Feb 2019 13:27:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: 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 20:28:00 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US 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=20 needed, perhaps a 'reviews' or 'discussion' list to split out=20 discussions (from anyone) from day-to-day patches? Also, I'd be anxious=20 about jumping to a new service like groups.io: most open source=20 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=20 web interface exists. One thing I feel that's missing from the current Github-based=20 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=20 hosting the API documentation at e.g.=20 https://code.bluestop.org/edk2/docs/master/ . Also, one thing a review=20 system like Gerrit, Github, Phabricator, Review Board etc. would give us = is the ability to run tests (lint, build/run OVMF etc.) against patches=20 and have it comment on the review about its status to give committers=20 more confidence in it. --=20 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, simila= r to today, folks encountering difficulties with our systems could reach = out to the TianoCore discussion venue (our mailing list or groups.io), an= d 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 o= ver 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 j= ust got back to this. >> >> Regarding "Patch Review System Evaluation", on the call, I disagreed w= ith your conclusion, but that note is not captured below. My reading of = the email and call discussions, I did not hear our community reject GitHu= b, rather observations that it was not "perfect", that it does not transp= arently interact with folks who prefer mailing list patch systems, but it= would be acceptable to try. On the call you mentioned a second justific= ation for staying with the mailing list system, that GitHub (really all m= odern patch management systems) exclude folks who have limited internet c= onnectivity. I hypothesize that this theoretical group of Tianocore cont= ributors would be a very small group of folks. Should our community opti= mize our systems for a very small, theoretical group, penalizing the over= whelming majority? I would propose that we try a modern patch management= system, GitHub had the best reviews in my reading, and folks with limite= d 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 stepha= no >> 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=3Dhttps%3A%2F%2Fww= w.tianocore.org%2Fminutes%2FCommunity-2019-01.html&data=3D02%7C01%7Cj= erecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f14= 1af91ab2d7cd011db47%7C1%7C0%7C636852311581785508&sdata=3DEVNgiM90x5nk= a9boa%2BVsCPVEJjib%2BfcDpQFLJ5m27cs%3D&reserved=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 usag= e on the UP Squared board and Beagle Bone Black. >> >> More info on FOSDEM here: >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ffo= sdem.org%2F2019%2F&data=3D02%7C01%7Cjerecox%40microsoft.com%7Ce198659= 4f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63= 6852311581795501&sdata=3D1weJ37WVTOJP4Et%2BgUJqF2KGIfV5g6IlGXEV8n0Lel= w%3D&reserved=3D0 >> >> Info on the talk here: >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ffo= sdem.org%2F2019%2Fschedule%2Fevent%2Fuefi_boot_for_mere_mortals%2F&da= ta=3D02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c= %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&sdat= a=3DBHkTSCSGQ71rh1G2zr%2FTFtxnzvUXK47vHES7hs0Cvh4%3D&reserved=3D0 >> >> Open Compute Project Global Summit >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.opencompute.org%2Fsummit%2Fglobal-summit&data=3D02%7C01%7Cjerecox%4= 0microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2= d7cd011db47%7C1%7C0%7C636852311581795501&sdata=3D8Wer0jAgTX2pMeHddxcN= dCXmAblGy5pVTfsotl6n1xE%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=3Dhttps%3A%2F%2Fsc= hed.co%2FJinT&data=3D02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f009= 4058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368523= 11581795501&sdata=3Dl3DULTiWsTfbxEoupZ1EbM6SJ2bsHFqK1rVIdl6oolY%3D&am= p;reserved=3D0 >> >> Other Upcoming Conferences >> Linuxfest NW >> PyCon >> Redhat Summit >> RustConf >> >> Rust >> ---- >> Stephano is working with some folks from the Open Source Technology Ce= nter at Intel regarding their desire to get Rust ported to EDK2. While th= ere are many proof of concepts out there, the first step for adoption wou= ld be to integrate the Rust infrastructure into our build system, and cre= ate a simple "hello world" app. The goal would be to provide a modern lan= guage with better memory safety for writing modules and drivers. Our hope= is that the availability of this language would encourage outside contri= bution and support from a vibrant and well established open source commun= ity. >> >> Github Discussions Evaluation, Groups.io, Microsoft Teams >> --------------------------------------------------------- >> During our December community meeting, we talked about trying out "Git= Hub Discussions" as a basis for communication that might be better than o= ur 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 us= ing 3 GitHub user accounts, and found the following shortcomings: >> >> 1. No support for uploading documents, only images 2. No way to archiv= e discussions outside GitHub[1] 3. Any comment can be edited by any membe= r 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 (ou= t of many) start having a =93sub discussion=94, their replies will not be= separate from the main thread. There=92s no way to distinguish and visua= lly =93collapse=94 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 notifica= tions are provided for these actions, so there may be no document trail f= or parts of the conversation. This system seems quite inadequate for seri= ous development discussions and is clearly meant for a more "chat" style = of communication on smaller teams. Comments and questions regarding "GitH= ub Discussions" are still welcomed, but Stephano recommends we move forwa= rd 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 t= he software options we have been evaluating have this cost barrier to ent= ry. 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 sta= tus, it might be easier for us to get non-profit discounts on software li= ke 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 u= p" (albeit distant). Also, Stephano / Nate from Intel will be reviewing G= errit use with a report being sent back to the community sometime next we= ek. >> >> 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 environ= ments are Linux, Windows, and macOS. >> We have compilers that are considered "supported" and those combinatio= ns should have proper coverage. Also, we do not want to use multiple CI e= nvironments, 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 M= S 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 overvi= ews and bug scrubs. Stephano will be working with Ray to set these up. Th= e 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 subm= itted. The design meetings could also be used to discuss RFC's from the m= ailing list. >> >> >> Thank you all for joining. As always, please feel free to email the li= st 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=3Dhttps%3A%2F%2Fli= sts.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=3D02%7C01%7Cjerecox= %40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91a= b2d7cd011db47%7C1%7C0%7C636852311581795501&sdata=3D%2ByLNjAyHNxw1oBxl= H6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&reserved=3D0 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fli= sts.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=3D02%7C01%7Cjerecox= %40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91a= b2d7cd011db47%7C1%7C0%7C636852311581795501&sdata=3D%2ByLNjAyHNxw1oBxl= H6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&reserved=3D0 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel