From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::136; helo=mail-it1-x136.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4D0D8208AE34C for ; Fri, 15 Feb 2019 00:43:36 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id g137so7076058ita.0 for ; Fri, 15 Feb 2019 00:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=myozuU3jyILBGEO/V3HNXnJBUslET5/MCYdVbqkUBUs=; b=a9tmmpGGtMbJ1qXKMhfQFd6f+EH4ceuBpUjN6fCl26MJsezWYmHlp3nXCScxZAiywm LkMuL+CWgu0hp7kHpZ93MOfsGOMRoO1jg8TpwOto7a6NTQ/HLe/w519mBDoQIjme/chM NkPbViDM88O4oAnjMqpVuwKY8DA18Z7rdHUZkjsMJargENZsSm+N37B64fgECkG3awev WfU77NsODctJnVyFydCJTtsHIh7WQJbhTI6fyZHfL2MmWykFe/niqigSbTLkWV7HnMfy NXxgwTFiQ9P/eIxdwIjs40JRsDd+oT+a7bW5rqp9meAw/8LBLWQO3mPaf/fp5DwR7gop 0jxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=myozuU3jyILBGEO/V3HNXnJBUslET5/MCYdVbqkUBUs=; b=QTDFH4fx5bysPa8NnaPiNIx9Y+65QRA98h7Ami8nnjwGOSky0fM3ZZE7rsRZpGASvg O1M33NSbyS+vKmbgYC/vc/LdpqEg9l26Bl1rr64Lovyi4EkVvBNzYrgzhu7m64pW1qOu S2h+qEfHMFpp4F9QG5T431jftc7YzXs4AXTJeyWT2IUniavvnqN1PhDOLQpesbovoYth xyRmc6BiEfpPeAS/yjtYmjYcRIVsS1CDlba+hFlRXscNHK/TAT9Zn+mogGngEHZWdQbe Yo9QX/ebAgVjNuBciN1erhttirvlCwlT9DjynRSxjfDiaxxw7elTDrr15njcOXO6MN39 Dgvw== X-Gm-Message-State: AHQUAuZ5JmtRejfH51wRJ8ED0rY5kVbhTPnzpGFSgkRimejyjX++OWbn oaMfANSnv9sYjvXSM95ZfZbHhxGzo8Y7Nc60ii/02A== X-Google-Smtp-Source: AHgI3IaSOoGlfjLHvDGr/6nt3/y8OdODrzR1c9Wli6VoWy7vHnGL76bz4DqJoSxWbVu6vDxWqSb5vcdPTDXghKuuefA= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr4611607itk.71.1550220214780; Fri, 15 Feb 2019 00:43:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Fri, 15 Feb 2019 09:43:23 +0100 Message-ID: To: Jeremiah Cox Cc: stephano , "edk2-devel@lists.01.org" , "Kinney, Michael D" , Laszlo Ersek 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: Fri, 15 Feb 2019 08:43:36 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 14 Feb 2019 at 20:07, Jeremiah Cox 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 t= o encourage a large number of UEFI developers who are currently closed to s= top 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 wa= ll. I think there is some value in this endeavor. > Fair enough. So now that we know which problem GitHub is the solution for, it might make sense to try and gain an understanding of how this is expected to improve things. In particular, since all EDK2 code going into products is marshaled by IBVs whose business model [currently] depends on not sharing any improvements they make to the code that they incorporate, could you explain where these contributions will be coming from, and how much they will deviate from [tested] code running on actual products? Also, as I explained before, in my view, open sourcing is *not* publishing your source code as an act of philanthropy after the product has shipped. It is about working with the community *during* development to build your software according to our common principles, so that upstreaming itself is seamless and does not lay a disproportional burden on the maintainers. So what is the nature of the contributions we are expecting? Surely, it is not the IBV value add being developed in the open from now on. It is likely a collection of platform ports that are going to be presented as-is, and if any changes are made to it by the contributors during review, it is never going to be reflected in the shipping devices, assuming I can even update the firmware on those. So forgive my cynicism, but I don't think Tianocore is the place for this. I think it may have value for a repository to exist where platform ports and unpolished vendor code can be published, but upstreaming involves more than that, and I would like to see more engagement from these contributors in the actual project before we start rebuilding our infrastructure around them. --=20 Ard. > ________________________________ > 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 ju= st got back to this. > > > > Regarding "Patch Review System Evaluation", on the call, I disagreed wi= th 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, ra= ther 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 s= taying with the mailing list system, that GitHub (really all modern patch m= anagement 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 fo= r 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 f= ind a friend to act as a go between translating their email diffs into GitH= ub 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 stephan= o > > 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%2Fwww= .tianocore.org%2Fminutes%2FCommunity-2019-01.html&data=3D02%7C01%7Cjere= cox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91= ab2d7cd011db47%7C1%7C0%7C636852311581785508&sdata=3DEVNgiM90x5nka9boa%2= BVsCPVEJjib%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 usage= on the UP Squared board and Beagle Bone Black. > > > > More info on FOSDEM here: > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ffos= dem.org%2F2019%2F&data=3D02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0= 094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368523= 11581795501&sdata=3D1weJ37WVTOJP4Et%2BgUJqF2KGIfV5g6IlGXEV8n0Lelw%3D&am= p;reserved=3D0 > > > > Info on the talk here: > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ffos= dem.org%2F2019%2Fschedule%2Fevent%2Fuefi_boot_for_mere_mortals%2F&data= =3D02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&sdata=3DBH= kTSCSGQ71rh1G2zr%2FTFtxnzvUXK47vHES7hs0Cvh4%3D&reserved=3D0 > > > > Open Compute Project Global Summit > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= .opencompute.org%2Fsummit%2Fglobal-summit&data=3D02%7C01%7Cjerecox%40mi= crosoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd0= 11db47%7C1%7C0%7C636852311581795501&sdata=3D8Wer0jAgTX2pMeHddxcNdCXmAbl= Gy5pVTfsotl6n1xE%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%2Fsch= ed.co%2FJinT&data=3D02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f009405= 8f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581= 795501&sdata=3Dl3DULTiWsTfbxEoupZ1EbM6SJ2bsHFqK1rVIdl6oolY%3D&reser= ved=3D0 > > > > Other Upcoming Conferences > > Linuxfest NW > > PyCon > > Redhat Summit > > RustConf > > > > Rust > > ---- > > Stephano is working with some folks from the Open Source Technology Cen= ter 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 s= imple "hello world" app. The goal would be to provide a modern language wit= h better memory safety for writing modules and drivers. Our hope is that th= e availability of this language would encourage outside contribution and su= pport 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 "GitH= ub 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 usi= ng 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 jus= t use email? > > > > That last one is particularly difficult to work around. Every comment i= s added to the bottom of the list. If some small group of developers (out o= f many) start having a =E2=80=9Csub discussion=E2=80=9D, their replies will= not be separate from the main thread. There=E2=80=99s no way to distinguis= h and visually =E2=80=9Ccollapse=E2=80=9D 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 f= or larger complex system design discussions. > > > > Also, the ability to edit comments is perplexing. Any member can edit a= ny comment, and delete any of their comments or edits. No email notificatio= ns are provided for these actions, so there may be no document trail for pa= rts of the conversation. This system seems quite inadequate for serious dev= elopment discussions and is clearly meant for a more "chat" style of commun= ication on smaller teams. Comments and questions regarding "GitHub Discussi= ons" are still welcomed, but Stephano recommends we move forward with tryin= g 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 som= e preliminary testing. If that goes well he will initiate discussions on "L= ine Endings" as well as "Use of C Standard Types". > > > > Microsoft Teams was also brought up as a possible solution. If Groups.i= o fails to provide a good platform for us, we will look into Teams. The mai= n barrier to entry there may be the cost. We have found that many of the so= ftware 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 com= munity. If TianoCore was an organization that had non-profit status, it mig= ht be easier for us to get non-profit discounts on software like this. Step= hano 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 p= ossible 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 Stewa= rd's meeting. It is important to remember that our supported environments a= re Linux, Windows, and macOS. > > We have compilers that are considered "supported" and those combination= s should have proper coverage. Also, we do not want to use multiple CI envi= ronments, so the solution we choose should support all use cases. > > There are several CI options that are "Free for open source" but they l= imit the size / number of CI agents, with pricing tiers for larger sized bu= ilds. The cost of a CI infrastructure will be dependent on the number of pa= tches we need to send through the service, and what kind of response is req= uired. Stephano will work with Philippe on Avacado, the folks at MS will ev= aluate possible use of Azure DevOps (again, possibly limited by the fact th= at we are not a non-profit), and volunteers are still required to test Cirr= us and Jenkins. > > > > Public Design / Bug Scrub Meetings > > ---------------------------------- > > We'd like to get public meetings started in February for design overvie= ws and bug scrubs. Stephano will be working with Ray to set these up. The h= ope is that we will have 1 meeting per month to start for bug scrubs. Desig= n 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 li= st. > > > > > > Thank you all for joining. As always, please feel free to email the lis= t 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%2Flis= ts.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=3D02%7C01%7Cjerecox%40= microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636852311581795501&sdata=3D%2ByLNjAyHNxw1oBxlH6wN%2B= kWK38tP1OsD9n4kCzK1SVg%3D&reserved=3D0 > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flis= ts.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=3D02%7C01%7Cjerecox%40= microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636852311581795501&sdata=3D%2ByLNjAyHNxw1oBxlH6wN%2B= kWK38tP1OsD9n4kCzK1SVg%3D&reserved=3D0