Re: [edk2-announce] Community Meeting Minutes

["Kinney, Michael D" <michael.d.kinney@intel.com>]

Rebecca,

You can review the groups.io features.  I think what you 
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 <jerecox@microsoft.com>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
> edk2-devel@lists.01.org; Laszlo Ersek
> <lersek@redhat.com>
> Subject: Re: [edk2] [edk2-announce] Community Meeting
> Minutes
> 
> 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.
> 
> 
> 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.
> 
> 
> --
> 
> 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, 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 <ard.biesheuvel@linaro.org>
> > 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
> > <edk2-devel@lists.01.org> 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 <edk2-devel-bounces@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.kinney@intel.com>;
> Laszlo Ersek <lersek@redhat.com>
> >> Subject: [edk2] [edk2-announce] Community Meeting
> Minutes
> >>
> >> An HTML version is available here:
> >>
> https://nam06.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-
> 2019-
> 01.html&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1
> 986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C636852311581785508&amp;sdata=EVNgi
> M90x5nka9boa%2BVsCPVEJjib%2BfcDpQFLJ5m27cs%3D&amp;reser
> ved=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=htt
> ps%3A%2F%2Ffosdem.org%2F2019%2F&amp;data=02%7C01%7Cjere
> cox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368523115
> 81795501&amp;sdata=1weJ37WVTOJP4Et%2BgUJqF2KGIfV5g6IlGX
> EV8n0Lelw%3D&amp;reserved=0
> >>
> >> Info on the talk here:
> >>
> https://nam06.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Ffosdem.org%2F2019%2Fschedule%2Fevent%2Fuefi_
> boot_for_mere_mortals%2F&amp;data=02%7C01%7Cjerecox%40m
> icrosoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f98
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C63685231158179550
> 1&amp;sdata=BHkTSCSGQ71rh1G2zr%2FTFtxnzvUXK47vHES7hs0Cv
> h4%3D&amp;reserved=0
> >>
> >> Open Compute Project Global Summit
> >>
> https://nam06.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-
> summit&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce19
> 86594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=8Wer0j
> AgTX2pMeHddxcNdCXmAblGy5pVTfsotl6n1xE%3D&amp;reserved=0
> >>
> >> No TianoCore talks were accepted for this event,
> however Stephano will be talking about CHIPSEC.
> >>
> https://nam06.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fsched.co%2FJinT&amp;data=02%7C01%7Cjerecox%4
> 0microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f
> 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795
> 501&amp;sdata=l3DULTiWsTfbxEoupZ1EbM6SJ2bsHFqK1rVIdl6oo
> lY%3D&amp;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=htt
> ps%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce198
> 6594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C636852311581795501&amp;sdata=%2ByLNj
> AyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserve
> d=0
> >> _______________________________________________
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >>
> https://nam06.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce198
> 6594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C636852311581795501&amp;sdata=%2ByLNj
> AyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserve
> d=0
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel