public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* [edk2-announce] Community Meeting Minutes
@ 2019-01-11 19:26 stephano
  2019-01-13  3:59 ` Rebecca Cran
  2019-02-07 17:52 ` Jeremiah Cox
  0 siblings, 2 replies; 26+ messages in thread
From: stephano @ 2019-01-11 19:26 UTC (permalink / raw)
  To: edk2-devel@lists.01.org
  Cc: Kinney, Michael D, Leif Lindholm, Laszlo Ersek, Andrew Fish

An HTML version is available here:
https://www.tianocore.org/minutes/Community-2019-01.html

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://fosdem.org/2019/

Info on the talk here:
https://fosdem.org/2019/schedule/event/uefi_boot_for_mere_mortals/

Open Compute Project Global Summit
https://www.opencompute.org/summit/global-summit

No TianoCore talks were accepted for this event, however Stephano will 
be talking about CHIPSEC.
https://sched.co/JinT

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



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-01-11 19:26 stephano
@ 2019-01-13  3:59 ` Rebecca Cran
  2019-01-14  9:28   ` Laszlo Ersek
  2019-01-14 17:06   ` stephano
  2019-02-07 17:52 ` Jeremiah Cox
  1 sibling, 2 replies; 26+ messages in thread
From: Rebecca Cran @ 2019-01-13  3:59 UTC (permalink / raw)
  To: edk2-devel; +Cc: stephano, Kinney, Michael D, Laszlo Ersek

On Friday, 11 January 2019 12:26:30 MST stephano wrote:

> 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.

I wonder if we might want to have a separate mailing list for reviews? 

I find it a bit overwhelming having both patches and more general discussions 
on the same list, since I only check it every few days.

-- 
Rebecca Cran




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-01-13  3:59 ` Rebecca Cran
@ 2019-01-14  9:28   ` Laszlo Ersek
  2019-01-14 17:06   ` stephano
  1 sibling, 0 replies; 26+ messages in thread
From: Laszlo Ersek @ 2019-01-14  9:28 UTC (permalink / raw)
  To: Rebecca Cran, stephano; +Cc: edk2-devel, Kinney, Michael D

On 01/13/19 04:59, Rebecca Cran wrote:
> On Friday, 11 January 2019 12:26:30 MST stephano wrote:
> 
>> 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.
> 
> I wonder if we might want to have a separate mailing list for reviews? 
> 
> I find it a bit overwhelming having both patches and more general discussions 
> on the same list, since I only check it every few days.
> 

I vaguely recall that this topic (separate mailing lists) has come up
before. I don't remember what the consensus was back then (or if there
was a consensus to begin with).

Personally, while I slightly prefer the single mailing list for now, I'd
certainly not oppose multiple mailing lists either. I could still filter
both "design" and "patch" lists into the same local folder.

Some pitfalls to consider:

- In some (infrequent) cases, a patch thread could be cross-posted to
the design list as well -- in such cases, it might be more difficult to
establish context for those people that are only subscribed to one of
the lists, or filter them to separate folders.

- If we have multiple lists, then we'll have to subscribe the agents of
external archivers to them separately (such as mail-archive.com).

- If we have multiple lists, and cannot lift the "subscribe to post"
requirement, then the initial inconvenience for participants could increase.

But, again, I totally understand Rebecca's perspective, and many open
source projects use different lists for different themes / emphases.

Thanks,
Laszlo


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-01-13  3:59 ` Rebecca Cran
  2019-01-14  9:28   ` Laszlo Ersek
@ 2019-01-14 17:06   ` stephano
  1 sibling, 0 replies; 26+ messages in thread
From: stephano @ 2019-01-14 17:06 UTC (permalink / raw)
  To: Rebecca Cran; +Cc: edk2-devel

On 1/12/2019 7:59 PM, Rebecca Cran wrote:

> I wonder if we might want to have a separate mailing list for reviews?
> 
> I find it a bit overwhelming having both patches and more general discussions
> on the same list, since I only check it every few days.
> 

My original thought was to add "edk2-announce" as a separate mailing 
list and keep the number of lists at 2 until we determine that more 
granularity is needed. While we decide on a new platform it was agreed 
(at the steward's meeting) that simply appending "edk2-announce" would 
suffice for now.

I have been trying out Groups.io and so far things look very promising:

https://edk2.groups.io/g/main

I added 2 subgroups: announce and devel. This allows us to keep 
community wide announcements (like this thread) separate from patch 
discussions. If we think that more granularity is needed (e.g. 
"architecture" for design discussions) we can discuss those possibilities.

Cheers,
Stephano


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-01-11 19:26 stephano
  2019-01-13  3:59 ` Rebecca Cran
@ 2019-02-07 17:52 ` Jeremiah Cox
  2019-02-07 18:30   ` stephano
  2019-02-08 13:58   ` Ard Biesheuvel
  1 sibling, 2 replies; 26+ messages in thread
From: Jeremiah Cox @ 2019-02-07 17:52 UTC (permalink / raw)
  To: stephano, edk2-devel@lists.01.org; +Cc: Kinney, Michael D, Laszlo Ersek

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-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=https%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-2019-01.html&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=QuHaAW3%2Fw3lPV8JnHskquCRJ6VlVCDNV2rptymjvCFY%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=rECfPlMrOzcpi5GSCBEHUFmycKMA7gshN82bAPcXw0I%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=smcg%2B0hTO8oI3yVThCcnB1j8pRWA37XTLrqeNeE8vos%3D&amp;reserved=0

Open Compute Project Global Summit
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-summit&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=gZpss9dmcJ7MqREcz%2FomaI8Un6157gM15%2FHTmOoOfyE%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=https%3A%2F%2Fsched.co%2FJinT&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=2PGlE%2Faop%2Bw5A3gnhOJCO4S09FuLc4lc%2FNbIMtcdLog%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=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=5pqGQCWQvCSsT17rw%2BhSMtgJEHsdPZ8vvZ%2F1yFniPkM%3D&amp;reserved=0

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-07 17:52 ` Jeremiah Cox
@ 2019-02-07 18:30   ` stephano
  2019-02-08  6:41     ` Rebecca Cran
  2019-02-08 13:58   ` Ard Biesheuvel
  1 sibling, 1 reply; 26+ messages in thread
From: stephano @ 2019-02-07 18:30 UTC (permalink / raw)
  To: Jeremiah Cox; +Cc: edk2-devel@lists.01.org, Laszlo Ersek

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-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=https%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-2019-01.html&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=QuHaAW3%2Fw3lPV8JnHskquCRJ6VlVCDNV2rptymjvCFY%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=rECfPlMrOzcpi5GSCBEHUFmycKMA7gshN82bAPcXw0I%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=smcg%2B0hTO8oI3yVThCcnB1j8pRWA37XTLrqeNeE8vos%3D&amp;reserved=0
> 
> Open Compute Project Global Summit
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-summit&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=gZpss9dmcJ7MqREcz%2FomaI8Un6157gM15%2FHTmOoOfyE%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=https%3A%2F%2Fsched.co%2FJinT&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=2PGlE%2Faop%2Bw5A3gnhOJCO4S09FuLc4lc%2FNbIMtcdLog%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=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=5pqGQCWQvCSsT17rw%2BhSMtgJEHsdPZ8vvZ%2F1yFniPkM%3D&amp;reserved=0
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-07 18:30   ` stephano
@ 2019-02-08  6:41     ` Rebecca Cran
  2019-02-08  9:01       ` Laszlo Ersek
  0 siblings, 1 reply; 26+ messages in thread
From: Rebecca Cran @ 2019-02-08  6:41 UTC (permalink / raw)
  To: edk2-devel; +Cc: stephano, Jeremiah Cox, Laszlo Ersek

On Thursday, 7 February 2019 11:30:38 MST stephano wrote:

> 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.

I wonder if Phabricator could be considered again, since I believe it supports 
all the features mentioned: the only thing it doesn't support as a first-class 
feature is mutli-patch reviews, which need to be done by linking separate 
reviews together using the dependency feature. I wonder if it could either be 
enhanced to support that, or people's workflow modified?

-- 
Rebecca Cran




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-08  6:41     ` Rebecca Cran
@ 2019-02-08  9:01       ` Laszlo Ersek
  2019-02-08 17:33         ` Rebecca Cran
  0 siblings, 1 reply; 26+ messages in thread
From: Laszlo Ersek @ 2019-02-08  9:01 UTC (permalink / raw)
  To: Rebecca Cran, edk2-devel

On 02/08/19 07:41, Rebecca Cran wrote:
> On Thursday, 7 February 2019 11:30:38 MST stephano wrote:
> 
>> 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.
> 
> I wonder if Phabricator could be considered again, since I believe it supports 
> all the features mentioned: the only thing it doesn't support as a first-class 
> feature is mutli-patch reviews, which need to be done by linking separate 
> reviews together using the dependency feature. I wonder if it could either be 
> enhanced to support that, or people's workflow modified?

I don't see the workflow modification as viable. The "patch series"
concept is integral to every single open source project that I've ever
worked with. The evolution of a feature or a bug fix over a series of
patches is a core facet of programming and reviewing. It communicates a
thinking process, and that's what programming is about.

Enhancing Phabricator is of course an option, but I'm not sure how
practical that is. Then we start talking time frames and it becomes sort
of a competition. If GitLab added features of fixed the grave issues we
had found with it, we'd have to re-evaluate GitLab too. Or else, if we
had a completely leisurely time frame at our disposal, I would 100% vote
<sr.ht> -- see the introduction at <https://lwn.net/Articles/775963/>.
<sr.ht> gets right *everything* right from the design principles; too
bad it's only Alpha at this point. So how long do we wait?

What I find practical at this moment is what Stephano has been working
on (thank you for all that Stephano) -- collect & file official
improvement requests with GitHub, and then see how those things are
addressed. In my opinion (not having seen Gerrit anyway, which remains
to be evaluated, but not by me), GitHub is the direct runner up to the
mailing list, so improving GitHub would be the most practical. In
particular I envision the context improvements for the GitHub email
notifications as something very doable for GitHub.

Thanks,
Laszlo


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-07 17:52 ` Jeremiah Cox
  2019-02-07 18:30   ` stephano
@ 2019-02-08 13:58   ` Ard Biesheuvel
  2019-02-14 19:07     ` Jeremiah Cox
  1 sibling, 1 reply; 26+ messages in thread
From: Ard Biesheuvel @ 2019-02-08 13:58 UTC (permalink / raw)
  To: Jeremiah Cox
  Cc: stephano, edk2-devel@lists.01.org, Kinney, Michael D,
	Laszlo Ersek

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=https%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-2019-01.html&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=QuHaAW3%2Fw3lPV8JnHskquCRJ6VlVCDNV2rptymjvCFY%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=rECfPlMrOzcpi5GSCBEHUFmycKMA7gshN82bAPcXw0I%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=smcg%2B0hTO8oI3yVThCcnB1j8pRWA37XTLrqeNeE8vos%3D&amp;reserved=0
>
> Open Compute Project Global Summit
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-summit&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=gZpss9dmcJ7MqREcz%2FomaI8Un6157gM15%2FHTmOoOfyE%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=https%3A%2F%2Fsched.co%2FJinT&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=2PGlE%2Faop%2Bw5A3gnhOJCO4S09FuLc4lc%2FNbIMtcdLog%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=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&amp;sdata=5pqGQCWQvCSsT17rw%2BhSMtgJEHsdPZ8vvZ%2F1yFniPkM%3D&amp;reserved=0
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-08  9:01       ` Laszlo Ersek
@ 2019-02-08 17:33         ` Rebecca Cran
  2019-02-08 17:52           ` Andrew Fish
  2019-02-08 20:33           ` Laszlo Ersek
  0 siblings, 2 replies; 26+ messages in thread
From: Rebecca Cran @ 2019-02-08 17:33 UTC (permalink / raw)
  To: Laszlo Ersek, edk2-devel


On February 8, 2019 at 2:01:59 AM, Laszlo Ersek (lersek@redhat.com(mailto:lersek@redhat.com)) wrote:

> I don't see the workflow modification as viable. The "patch series"
> concept is integral to every single open source project that I've ever
> worked with. The evolution of a feature or a bug fix over a series of
> patches is a core facet of programming and reviewing. It communicates a
> thinking process, and that's what programming is about.  

I don’t recall coming across the patch series (e.g. the 1/5 email patches) in other projects. In other projects people post a single patch and then update it following feedback on the same review. This can be either in a single, rebased commit, or new commits on a bug/feature branch - review systems deal with both.

> So how long do we wait?
>  


Good point!  

>  
>  
> What I find practical at this moment is what Stephano has been working
> on (thank you for all that Stephano) -- collect & file official
> improvement requests with GitHub, and then see how those things are
> addressed. In my opinion (not having seen Gerrit anyway, which remains
> to be evaluated, but not by me), GitHub is the direct runner up to the
> mailing list, so improving GitHub would be the most practical. In
> particular I envision the context improvements for the GitHub email
> notifications as something very doable for GitHub.  





I’d certainly be happy to use Github, but I do worry about tieing ourselves to such a closed system.






Rebecca



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-08 17:33         ` Rebecca Cran
@ 2019-02-08 17:52           ` Andrew Fish
  2019-02-22 11:52             ` Rebecca Cran
  2019-02-08 20:33           ` Laszlo Ersek
  1 sibling, 1 reply; 26+ messages in thread
From: Andrew Fish @ 2019-02-08 17:52 UTC (permalink / raw)
  To: Rebecca Cran; +Cc: Laszlo Ersek, edk2-devel



> On Feb 8, 2019, at 9:33 AM, Rebecca Cran via edk2-devel <edk2-devel@lists.01.org> wrote:
> 
> 
> On February 8, 2019 at 2:01:59 AM, Laszlo Ersek (lersek@redhat.com(mailto:lersek@redhat.com)) wrote:
> 
>> I don't see the workflow modification as viable. The "patch series"
>> concept is integral to every single open source project that I've ever
>> worked with. The evolution of a feature or a bug fix over a series of
>> patches is a core facet of programming and reviewing. It communicates a
>> thinking process, and that's what programming is about.  
> 
> I don’t recall coming across the patch series (e.g. the 1/5 email patches) in other projects. In other projects people post a single patch and then update it following feedback on the same review. This can be either in a single, rebased commit, or new commits on a bug/feature branch - review systems deal with both.
> 

Rebecca,

I think the patch workflow is kind of like a coding standards. Some folks advocate for lots of small patches (common in open source projects), and some folks advocate for a patch per bug. I think the biggest upside to the patch granularity is it is much easier to bisect a failure. 

So I've used Bitbucket with a branch per commit (you name your branch with a standard pattern and the bugzilla  ) model and if your branch has a patch series (set of commits) you can view each commit independently from the UI and the default view is the entire patch series. So you can see both. 

Thanks,

Andrew Fish


>> So how long do we wait?
>> 
> 
> 
> Good point!  
> 
>> 
>> 
>> What I find practical at this moment is what Stephano has been working
>> on (thank you for all that Stephano) -- collect & file official
>> improvement requests with GitHub, and then see how those things are
>> addressed. In my opinion (not having seen Gerrit anyway, which remains
>> to be evaluated, but not by me), GitHub is the direct runner up to the
>> mailing list, so improving GitHub would be the most practical. In
>> particular I envision the context improvements for the GitHub email
>> notifications as something very doable for GitHub.  
> 
> 
> 
> 
> 
> I’d certainly be happy to use Github, but I do worry about tieing ourselves to such a closed system.
> 
> 
> 
> 
> 
> 
> Rebecca
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-08 17:33         ` Rebecca Cran
  2019-02-08 17:52           ` Andrew Fish
@ 2019-02-08 20:33           ` Laszlo Ersek
  1 sibling, 0 replies; 26+ messages in thread
From: Laszlo Ersek @ 2019-02-08 20:33 UTC (permalink / raw)
  To: Rebecca Cran, edk2-devel

On 02/08/19 18:33, Rebecca Cran wrote:
> 
> On February 8, 2019 at 2:01:59 AM, Laszlo Ersek (lersek@redhat.com(mailto:lersek@redhat.com)) wrote:
> 
>> I don't see the workflow modification as viable. The "patch series"
>> concept is integral to every single open source project that I've ever
>> worked with. The evolution of a feature or a bug fix over a series of
>> patches is a core facet of programming and reviewing. It communicates a
>> thinking process, and that's what programming is about.  
> 
> I don’t recall coming across the patch series (e.g. the 1/5 email patches) in other projects. In other projects people post a single patch and then update it following feedback on the same review. This can be either in a single, rebased commit, or new commits on a bug/feature branch - review systems deal with both.

How do they contribute a feature consisting of 1500-3000 lines, in one
well-structured, coherent "package"? I don't think that any single patch
can carry that weight. Only a patch series can.

Regarding "new commits on a bug/feature branch" -- that really doesn't
look good to me, as a way to develop a focused, larger feature. Even if
the initial patch looks good (in separation), it cannot really be
evaluated without getting some kind of perspective, i.e. seeing where
the whole thing leads in mid-distance. Sometimes we find a design bug in
patch 08/12 that invalidates patch 03/12. I wouldn't want to push 03/12
until I review (and maybe even test / regression-test) the full dozen.

We need this to scale to 50+ patches in a series. Such a series is not
posted every day, but it does happen. That's when we need the tooling to
carry us the most.

[...]

Obviously: I welcome all comments on this, in disagreement too!

Thanks!
Laszlo


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-08 13:58   ` Ard Biesheuvel
@ 2019-02-14 19:07     ` Jeremiah Cox
  2019-02-14 20:27       ` Rebecca Cran
  2019-02-15  8:43       ` Ard Biesheuvel
  0 siblings, 2 replies; 26+ messages in thread
From: Jeremiah Cox @ 2019-02-14 19:07 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: stephano, edk2-devel@lists.01.org, Kinney, Michael D,
	Laszlo Ersek

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=https%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-2019-01.html&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581785508&amp;sdata=EVNgiM90x5nka9boa%2BVsCPVEJjib%2BfcDpQFLJ5m27cs%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=1weJ37WVTOJP4Et%2BgUJqF2KGIfV5g6IlGXEV8n0Lelw%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=BHkTSCSGQ71rh1G2zr%2FTFtxnzvUXK47vHES7hs0Cvh4%3D&amp;reserved=0
>
> Open Compute Project Global Summit
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-summit&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=8Wer0jAgTX2pMeHddxcNdCXmAblGy5pVTfsotl6n1xE%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=https%3A%2F%2Fsched.co%2FJinT&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=l3DULTiWsTfbxEoupZ1EbM6SJ2bsHFqK1rVIdl6oolY%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=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=%2ByLNjAyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserved=0
> _______________________________________________
> 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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=%2ByLNjAyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserved=0


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-14 19:07     ` Jeremiah Cox
@ 2019-02-14 20:27       ` Rebecca Cran
  2019-02-14 22:13         ` Kinney, Michael D
  2019-02-15  8:43       ` Ard Biesheuvel
  1 sibling, 1 reply; 26+ messages in thread
From: Rebecca Cran @ 2019-02-14 20:27 UTC (permalink / raw)
  To: Jeremiah Cox, Ard Biesheuvel
  Cc: Kinney, Michael D, edk2-devel@lists.01.org, Laszlo Ersek

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=https%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-2019-01.html&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581785508&amp;sdata=EVNgiM90x5nka9boa%2BVsCPVEJjib%2BfcDpQFLJ5m27cs%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=1weJ37WVTOJP4Et%2BgUJqF2KGIfV5g6IlGXEV8n0Lelw%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=BHkTSCSGQ71rh1G2zr%2FTFtxnzvUXK47vHES7hs0Cvh4%3D&amp;reserved=0
>>
>> Open Compute Project Global Summit
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-summit&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=8Wer0jAgTX2pMeHddxcNdCXmAblGy5pVTfsotl6n1xE%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=https%3A%2F%2Fsched.co%2FJinT&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=l3DULTiWsTfbxEoupZ1EbM6SJ2bsHFqK1rVIdl6oolY%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=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=%2ByLNjAyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserved=0
>> _______________________________________________
>> 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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=%2ByLNjAyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserved=0
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-14 20:27       ` Rebecca Cran
@ 2019-02-14 22:13         ` Kinney, Michael D
  2019-02-15  2:56           ` Rebecca Cran
  0 siblings, 1 reply; 26+ messages in thread
From: Kinney, Michael D @ 2019-02-14 22:13 UTC (permalink / raw)
  To: Rebecca Cran, Jeremiah Cox, Ard Biesheuvel,
	edk2-devel@lists.01.org, Kinney, Michael D
  Cc: Laszlo Ersek

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


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-14 22:13         ` Kinney, Michael D
@ 2019-02-15  2:56           ` Rebecca Cran
  2019-02-15 14:30             ` Laszlo Ersek
  2019-02-15 17:55             ` stephano
  0 siblings, 2 replies; 26+ messages in thread
From: Rebecca Cran @ 2019-02-15  2:56 UTC (permalink / raw)
  To: Kinney, Michael D, Jeremiah Cox, Ard Biesheuvel,
	edk2-devel@lists.01.org
  Cc: Laszlo Ersek

On 2/14/19 3:13 PM, Kinney, Michael D wrote:
> 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.


Thanks, I'm cautiously optimistic that groups.io will maintain a nice 
email interface to the list(s). However I don't see any messages/topics 
(in https://edk2.groups.io/g/main), and it appears my test posts are 
being moderated: are there plans to start active testing at some point?


I'm not sure I'll ever be a fan of Github but hopefully it's something 
we can move forward with - and I'll continue providing other services I 
feel are missing, from the server in my basement :)


-- 
Rebecca Cran



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-14 19:07     ` Jeremiah Cox
  2019-02-14 20:27       ` Rebecca Cran
@ 2019-02-15  8:43       ` Ard Biesheuvel
  2019-02-15 14:23         ` Laszlo Ersek
  1 sibling, 1 reply; 26+ messages in thread
From: Ard Biesheuvel @ 2019-02-15  8:43 UTC (permalink / raw)
  To: Jeremiah Cox
  Cc: stephano, edk2-devel@lists.01.org, Kinney, Michael D,
	Laszlo Ersek

On Thu, 14 Feb 2019 at 20:07, Jeremiah Cox <jerecox@microsoft.com> 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.
>

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.

-- 
Ard.


> ________________________________
> 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=https%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-2019-01.html&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581785508&amp;sdata=EVNgiM90x5nka9boa%2BVsCPVEJjib%2BfcDpQFLJ5m27cs%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=1weJ37WVTOJP4Et%2BgUJqF2KGIfV5g6IlGXEV8n0Lelw%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=BHkTSCSGQ71rh1G2zr%2FTFtxnzvUXK47vHES7hs0Cvh4%3D&amp;reserved=0
> >
> > Open Compute Project Global Summit
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-summit&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=8Wer0jAgTX2pMeHddxcNdCXmAblGy5pVTfsotl6n1xE%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=https%3A%2F%2Fsched.co%2FJinT&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=l3DULTiWsTfbxEoupZ1EbM6SJ2bsHFqK1rVIdl6oolY%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=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=%2ByLNjAyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserved=0
> > _______________________________________________
> > 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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Ce1986594f0094058f09208d68dcd9b0c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852311581795501&amp;sdata=%2ByLNjAyHNxw1oBxlH6wN%2BkWK38tP1OsD9n4kCzK1SVg%3D&amp;reserved=0


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-15  8:43       ` Ard Biesheuvel
@ 2019-02-15 14:23         ` Laszlo Ersek
  2019-02-15 19:54           ` Felix Polyudov
  0 siblings, 1 reply; 26+ messages in thread
From: Laszlo Ersek @ 2019-02-15 14:23 UTC (permalink / raw)
  To: Ard Biesheuvel, Jeremiah Cox
  Cc: stephano, edk2-devel@lists.01.org, Kinney, Michael D

Just a short comment below.

(Not changing my stance in any way that I've presented thus far; the
comment is only meant in addition to / as a clarification for that.)

On 02/15/19 09:43, Ard Biesheuvel wrote:

> I would like to see more engagement from these contributors in the
> actual project before we start rebuilding our infrastructure around
> them.

Agreed. In my opinion, some public "testimonials" would be nice, such as

  Yes, the mailing list based workflow is the one thing that prevents us
  from sharing patches, listening to and addressing reviews, posting
  updated patches, and commenting on others' patches.

Thanks,
Laszlo


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-15  2:56           ` Rebecca Cran
@ 2019-02-15 14:30             ` Laszlo Ersek
  2019-02-15 17:55             ` stephano
  1 sibling, 0 replies; 26+ messages in thread
From: Laszlo Ersek @ 2019-02-15 14:30 UTC (permalink / raw)
  To: Rebecca Cran
  Cc: Kinney, Michael D, Jeremiah Cox, Ard Biesheuvel,
	edk2-devel@lists.01.org, Stephano Cetola

On 02/15/19 03:56, Rebecca Cran wrote:
> On 2/14/19 3:13 PM, Kinney, Michael D wrote:
>> 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.
> 
> 
> Thanks, I'm cautiously optimistic that groups.io will maintain a nice
> email interface to the list(s). However I don't see any messages/topics
> (in https://edk2.groups.io/g/main), and it appears my test posts are
> being moderated: are there plans to start active testing at some point?

Yes, there are. I recommended the following steps yesterday, in a
discussion with Stephano. (Note: I think it was OK for Stephano to ping
me off-list; the mistake was on my side, when I also responded off-list.
The plan I was suggesting should have been public immediately.)

Given the setting, in the plan I referred to Stephano and myself as the
two testers collaborating. Obviously this plan can be executed by any
two contributors. For simplicity (and for fear of messing up the plan
with over-editing), I'll keep the plan as it was. Thanks.

(01) Stephano subscribes to the new list.
(02) I don't.
(03) I post a message to the new list address, with an attachment.
     I don't CC anyone personally.
(04) Stephano confirms whether he got the message through the list,
     including the attachment.
(05) If Stephano didn't get my message, he white-lists me, and we repeat
     steps (03) and (04).
(06) We check whether the archive of the new list offers both the
     message and the attachment.
(07) Stephano hits "Reply All" in his MUA. I should get one copy of his
     email (the direct one, as I'm not subscribed to the list).
(08) I subscribe.
(09) Stephano sends an email, addressing both the list and me. I should
     get two copies, with different email headers, suitable for
     filtering.
(10) I hit "Reply All".
(11) Stephano hits "Reply All".
(12) I check both locally, and in the web archive, whether the threading
     is nested (that is, not flattened), over steps (09) through (11).
(13) On all messages we receive from the list, we confirm that the
     "Reply-To" header is *absent*.
(14) I post a patch to the list, with git-send-email.
(15) I receive a copy of the patch, through the list.
(16) The patch is not corrupted; it applies well with git-am.
(17) The patch can be retrieved from the web achive, and it applies
     well with git-am.

Coordination around the steps, mid execution, can occur in off-list
(private) emails, or even on edk2-devel, if that's deemed better. (The
point is to avoid meta-traffic on the new list while we are testing the
new list.)

Thanks!
Laszlo

> I'm not sure I'll ever be a fan of Github but hopefully it's something
> we can move forward with - and I'll continue providing other services I
> feel are missing, from the server in my basement :)
> 
> 



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-15  2:56           ` Rebecca Cran
  2019-02-15 14:30             ` Laszlo Ersek
@ 2019-02-15 17:55             ` stephano
  1 sibling, 0 replies; 26+ messages in thread
From: stephano @ 2019-02-15 17:55 UTC (permalink / raw)
  To: edk2-devel

On 2/14/2019 6:56 PM, Rebecca Cran via edk2-devel wrote:
> Thanks, I'm cautiously optimistic that groups.io will maintain a nice 
> email interface to the list(s). However I don't see any messages/topics 
> (in https://edk2.groups.io/g/main), and it appears my test posts are 
> being moderated: are there plans to start active testing at some point?

I was actively testing on a different group so as not to confuse people, 
but you're (un)moderated now, so you should be able to post. :)

My initial thought is that going forward we should not moderate posts at 
all, and rather ban people who abuse the list. This makes me wonder how 
good their spam filters are at groups.io.

Cheers,
Stephano


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-15 14:23         ` Laszlo Ersek
@ 2019-02-15 19:54           ` Felix Polyudov
  2019-02-15 22:53             ` Laszlo Ersek
  0 siblings, 1 reply; 26+ messages in thread
From: Felix Polyudov @ 2019-02-15 19:54 UTC (permalink / raw)
  To: 'Laszlo Ersek', Ard Biesheuvel, Jeremiah Cox
  Cc: Kinney, Michael D, edk2-devel@lists.01.org

> -----Original Message-----
> From: Laszlo Ersek
> Sent: Friday, February 15, 2019 9:23 AM
>
> Just a short comment below.
>
> (Not changing my stance in any way that I've presented thus far; the
> comment is only meant in addition to / as a clarification for that.)
>
> On 02/15/19 09:43, Ard Biesheuvel wrote:
>
> > I would like to see more engagement from these contributors in the
> > actual project before we start rebuilding our infrastructure around
> > them.
>
> Agreed. In my opinion, some public "testimonials" would be nice, such as
>
>   Yes, the mailing list based workflow is the one thing that prevents us
>   from sharing patches, listening to and addressing reviews, posting
>   updated patches, and commenting on others' patches.

For AMI and for me personally mailing list based workflow is one of the factors that limits our level of engagement.
I've done a few patch submissions, but I have yet to figure out how to make applying embedded patches work in my Windwos & Outlook configuration.

Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends, Inc.  This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited.  Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-15 19:54           ` Felix Polyudov
@ 2019-02-15 22:53             ` Laszlo Ersek
  0 siblings, 0 replies; 26+ messages in thread
From: Laszlo Ersek @ 2019-02-15 22:53 UTC (permalink / raw)
  To: Felix Polyudov, Ard Biesheuvel, Jeremiah Cox
  Cc: Kinney, Michael D, edk2-devel@lists.01.org

On 02/15/19 20:54, Felix Polyudov wrote:
>> -----Original Message-----
>> From: Laszlo Ersek
>> Sent: Friday, February 15, 2019 9:23 AM
>>
>> Just a short comment below.
>>
>> (Not changing my stance in any way that I've presented thus far; the
>> comment is only meant in addition to / as a clarification for that.)
>>
>> On 02/15/19 09:43, Ard Biesheuvel wrote:
>>
>>> I would like to see more engagement from these contributors in the
>>> actual project before we start rebuilding our infrastructure around
>>> them.
>>
>> Agreed. In my opinion, some public "testimonials" would be nice, such as
>>
>>   Yes, the mailing list based workflow is the one thing that prevents us
>>   from sharing patches, listening to and addressing reviews, posting
>>   updated patches, and commenting on others' patches.
> 
> For AMI and for me personally mailing list based workflow is one of the factors that limits our level of engagement.
> I've done a few patch submissions, but I have yet to figure out how to make applying embedded patches work in my Windwos & Outlook configuration.

Thank you.
Laszlo


^ permalink raw reply	[flat|nested] 26+ messages in thread

* [edk2-announce] Community Meeting Minutes
@ 2019-02-20  6:23 stephano
  2019-02-20  6:45 ` stephano
  2019-02-20  7:49 ` Rebecca Cran
  0 siblings, 2 replies; 26+ messages in thread
From: stephano @ 2019-02-20  6:23 UTC (permalink / raw)
  To: edk2-devel@lists.01.org

An HTML version is available here:
https://www.tianocore.org/minutes/Community-2019-02.html

Github Pull Requests
---------------------
We are still considering Github as a possible platform for patch review. 
There are two issues we'd like to overcome:

1. comprehensive email notifications or backup/archival functionality
2. workflow for users that do not have a consistent internet connection

The notification issue degrades our current ability to archive the 
history of a patch review. Github notifications do not provide:

1. the subject line of the patch
2. trailing code context of comments (code that comes AFTER the comment)
3. the commit message

In this way, it is hard to avoid losing the meaning of the pull request 
conversation if we were to move to a different system some day. The 
longevity of PR branches is also a concern, and a workaround would need 
to be found and maintained. We need to be sure that PR branches can be 
easily archived so that if a Github user deletes their account, even if 
their PR was rejected, the code would be available.

Jeremiah and I are both looking for work around to these issues, 
hopefully without having to maintain more code. See here for details on 
Laszlo's thorough Github evaluation:

https://lists.01.org/pipermail/edk2-devel/2018-December/033509.html

To be clear, these hurtles do not *have to be* overcome. They were 
brought up by several maintainers and community members. They are simply 
barriers that we want to discuss fully before committing to a 
transition. It is impossible to "change our mind" on this transition 
without some loss of data, so best we be sure before we switch.

Working in a community means providing consistent messaging, clear 
expectations, and the understanding that each member is valuable. 
Working in the open means moderating, evaluating, and distilling input 
from community members and companies without bias or prejudice. I take 
this transition seriously and do not plan to rush it.

Gerrit Code Review
---------------------
Gerrit code review is viable platform, but Intel's implementation of the 
'repo' tool is still working on being open sourced. Also, there would be 
a lot of work that would go into implementing a proper Gerrit solution. 
If someone would like to volunteer to carry this out, please feel free 
to contact me, but I'm going to postpone this for the moment as my 
schedule is rather full.

Groups.io
---------------------
Laszlo and I will evaluate Groups.io, however initial impressions is 
that this will work as a communication platform going forward. We'd like 
to use this for design discussions and as a replacement for our current 
mailing list as 01.org does not allow attachments or whistling. Also, 
Groups.io allows for online search of the list, chats, and uploads which 
is much easier for some than searching through emails. Assuming this is 
successful, I will work with 01.org to archive all (if possible) of the 
edk2-devel mailing list into groups.io for a (mostly) seamless 
transition. I will see how long 01.org is willing to store archives, and 
will notify the community of how long that archive will be available.

Community Bug Triage
---------------------
Community bug triage meetings will occur every two weeks, and we will 
have 2 meetings to accommodate both sets of timezones. See here for details:

https://www.tianocore.org/bug-triage/

I will be working to develop bugzilla reports and researching possible 
platforms that we could add to a community CI. Maintaining these 
platforms would be a great way to add to the list of community bugs and 
encourage open development.

Community Design
---------------------
We will be starting the community design meetings in March and holding 
them every 2 weeks. If we find that there are enough submissions we can 
meet every week. I will hold two meetings, much like the community 
meetings. Any submission will be discussed in both meeting and notes 
sent out in the meeting minutes. Discussion can then continue on the 
mailing list. I will send out an RFC for folks to submit possible topics 
the day before each meeting.

Rust in EDK II Exploration Notes
------------------------------------------
I have been working with the Rust community, as well as members of 
Intel's Firmware Security teams, to explore the benefits of using Rust 
in EDK II. For those of you who have never heard of Rust, please take 
some time to look into it:

https://en.wikipedia.org/wiki/Rust_(programming_language)

Here is a brief overview of the pros/cons:

Benefits of Rust
Rust is a modern language with features like counted buffers and 
strings. It can call C code and be called by C code. It requires no 
calls to "free", and does so without garbage collection by statically 
inserting calls to "free" for you. Rust types keep track of which 
structs own which memory chunks so that developers do not have to keep 
track of ownership of struct memory. Rust includes a lot of 
functionality not found in C. These features include Unicode support, an 
ecosystem library, structural types, and matching (it is very easy to 
wrap types as a "SUCCESS" or "FAILURE WITH ERROR CODE"). Rust has no 
NULL pointers as that concept has its own type, which makes for cleaner 
semantics. It has a robust built in macro system. For example, when you 
get a compilation error in code calling a macro, the compiler will be 
able to show you where in the macro the failure occurred.

Drawbacks of Rust
Rust is a younger language, though there are many examples of where it 
has been used in production. As such, many features one might take for 
granted in C still do not exist in Rust, or are newly added. For 
example, variadic functions (varargs) were just recently added. There 
are other corner cases of "things you can do in C" that still need to be 
added. Rust does have a great package management system (called cargo - 
crates are packages), but in a system like EDK2, we will want to limit 
those outside dependencies. Sub-command cargo-vendor is a tool where you 
can pin package versions and update them only as needed.

TianoCore in the News
---------------------
Here's my presentation from FOSDEM:

https://fosdem.org/2019/schedule/event/uefi_boot_for_mere_mortals/

I collaborated with Alexander Graf from SUSE. I'll be giving this talk 
again at LinuxFest Northwest (http://linuxfestnorthwest.org).

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


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-20  6:23 [edk2-announce] Community Meeting Minutes stephano
@ 2019-02-20  6:45 ` stephano
  2019-02-20  7:49 ` Rebecca Cran
  1 sibling, 0 replies; 26+ messages in thread
From: stephano @ 2019-02-20  6:45 UTC (permalink / raw)
  To: edk2-devel

On 2/19/2019 10:23 PM, stephano wrote:
> 
> Groups.io
> ---------------------
> Laszlo and I will evaluate Groups.io, however initial impressions is 
> that this will work as a communication platform going forward. We'd like 
> to use this for design discussions and as a replacement for our current 
> mailing list as 01.org does not allow attachments or whistling.

I have double checked, and indeed, 01.org does not allow whistling of 
any kind. Thank you autocorrect for that insightful suggestion.

I would like to note that 01.org also does not allow white-listing, 
something perhaps more valuable to our community.

Kind Regards,
Stephano


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-20  6:23 [edk2-announce] Community Meeting Minutes stephano
  2019-02-20  6:45 ` stephano
@ 2019-02-20  7:49 ` Rebecca Cran
  1 sibling, 0 replies; 26+ messages in thread
From: Rebecca Cran @ 2019-02-20  7:49 UTC (permalink / raw)
  To: edk2-devel

On Tuesday, 19 February 2019 23:23:59 MST stephano wrote:

> Github Pull Requests
> ---------------------
> We are still considering Github as a possible platform for patch review.

One thing I've not seen mentioned here is that there's an official command line 
tool for GitHub, named 'hub': https://hub.github.com/

>From the output of 'hub --help':

These GitHub commands are provided by hub:

   browse         Open a GitHub page in the default browser
   ci-status      Show the status of GitHub checks for a commit
   compare        Open a compare page on GitHub
   create         Create this repository on GitHub and add GitHub as origin
   delete         Delete a repository on GitHub
   fork           Make a fork of a remote repository on GitHub and add as 
remote
   issue          List or create GitHub issues
   pr             List or checkout GitHub pull requests
   pull-request   Open a pull request on GitHub
   release        List or create GitHub releases
   sync           Fetch git objects from upstream and update branches


-- 
Rebecca Cran




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [edk2-announce] Community Meeting Minutes
  2019-02-08 17:52           ` Andrew Fish
@ 2019-02-22 11:52             ` Rebecca Cran
  0 siblings, 0 replies; 26+ messages in thread
From: Rebecca Cran @ 2019-02-22 11:52 UTC (permalink / raw)
  To: Andrew Fish; +Cc: Laszlo Ersek, edk2-devel

On 2/8/19 10:52 AM, Andrew Fish wrote:

> I think the patch workflow is kind of like a coding standards. Some folks advocate for lots of small patches (common in open source projects), and some folks advocate for a patch per bug. I think the biggest upside to the patch granularity is it is much easier to bisect a failure.
>
> So I've used Bitbucket with a branch per commit (you name your branch with a standard pattern and the bugzilla  ) model and if your branch has a patch series (set of commits) you can view each commit independently from the UI and the default view is the entire patch series. So you can see both.


I think I see the difference now: I've used several review systems, most 
recently including Bitbucket, and with Review Board, Phabricator, and I 
think Gerrit people tend to post several patches against the same bug, 
often not labeling them as patch 1/3, 2/3 etc. but just using the same 
bug number.

Seeing the entire series clearly as an email thread on here is rather nice.


-- 

Rebecca Cran



^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2019-02-22 11:52 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-20  6:23 [edk2-announce] Community Meeting Minutes stephano
2019-02-20  6:45 ` stephano
2019-02-20  7:49 ` Rebecca Cran
  -- strict thread matches above, loose matches on Subject: below --
2019-01-11 19:26 stephano
2019-01-13  3:59 ` Rebecca Cran
2019-01-14  9:28   ` Laszlo Ersek
2019-01-14 17:06   ` stephano
2019-02-07 17:52 ` Jeremiah Cox
2019-02-07 18:30   ` stephano
2019-02-08  6:41     ` Rebecca Cran
2019-02-08  9:01       ` Laszlo Ersek
2019-02-08 17:33         ` Rebecca Cran
2019-02-08 17:52           ` Andrew Fish
2019-02-22 11:52             ` Rebecca Cran
2019-02-08 20:33           ` Laszlo Ersek
2019-02-08 13:58   ` Ard Biesheuvel
2019-02-14 19:07     ` Jeremiah Cox
2019-02-14 20:27       ` Rebecca Cran
2019-02-14 22:13         ` Kinney, Michael D
2019-02-15  2:56           ` Rebecca Cran
2019-02-15 14:30             ` Laszlo Ersek
2019-02-15 17:55             ` stephano
2019-02-15  8:43       ` Ard Biesheuvel
2019-02-15 14:23         ` Laszlo Ersek
2019-02-15 19:54           ` Felix Polyudov
2019-02-15 22:53             ` Laszlo Ersek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox