Re: [edk2] [edk2-announce] Community Meeting Minutes

[Jeremiah Cox via edk2-devel]

Hi Ard,
My apologies as no insult was intended.  The suggestion is that, similar to 
today, folks encountering difficulties with our systems could reach out to the 
TianoCore discussion venue (our mailing list or groups.io), and our friendly 
community members (we have many) will surely assist them.

You are correct that my focus is not casual contributors, rather I want to 
encourage a large number of UEFI developers who are currently closed to stop 
their fork-modify-ship model, which is inefficient to service, go open to share 
their learnings, get current, stay current, upstream their changes (where it 
makes sense to the community), but not throw garbage over the wall.   I think 
there is some value in this endeavor.

Kind Regards,
Jeremiah


From: Ard Biesheuvel 
Sent: Friday, February 8, 2019 5:58 AM
To: Jeremiah Cox
Cc: stephano; edk2-devel@lists.01.org; Kinney, Michael D; Laszlo Ersek
Subject: Re: [edk2] [edk2-announce] Community Meeting Minutes

On Thu, 7 Feb 2019 at 18:52, Jeremiah Cox via edk2-devel
 wrote:
>
> Apologies on the late reply, I was on vacation for several weeks and just got 
> back to this.
>
> Regarding "Patch Review System Evaluation", on the call, I disagreed with 
> your conclusion, but that note is not captured below.  My reading of the 
> email and call discussions, I did not hear our community reject GitHub, 
> rather observations that it was not "perfect", that it does not transparently 
> interact with folks who prefer mailing list patch systems, but it would be 
> acceptable to try.  On the call you mentioned a second justification for 
> staying with the mailing list system, that GitHub (really all modern patch 
> management systems) exclude folks who have limited internet connectivity.  I 
> hypothesize that this theoretical group of Tianocore contributors would be a 
> very small group of folks.  Should our community optimize our systems for a 
> very small, theoretical group, penalizing the overwhelming majority?  I would 
> propose that we try a modern patch management system, GitHub had the best 
> reviews in my reading, and folks with limited internet connectivity find a 
> friend to act as a go between translating their email diffs into GitHub PRs.

I find this unnecessarily condescending. Finding a friend, seriously?

Very serious concerns have been raised about the lack of transparency
with the various systems, and the fact that I am able to consult my
own local copy of the entire review history, including all email
exchanges is a very important aspect of the current model to me, as
opposed to GitHub deciding what is important enough to keep and what
is not. In an open source project, the code base is *not* the HEAD
commit, it is the entire repository, including history, and logged
email threads with technical discussions, since they are usually not
captured in other ways.

The push to GitHub is being sold to us as a way to attract more
contributors, but it seems to me (and I have stated this multiple
times) that the mailing list is not the steep part of the learning
curve when contributing to TianoCore. So is this really about getting
outsiders to contribute to Tianocore? Or is it about reducing the
impedance mismatch with what internal teams at MicroSoft (and Intel?)
are doing, which probably already went through the learning curve when
it comes to other aspects of Tianocore.

>From a high level, it might seem that using a mailing list is the
impediment here. But in reality, contributing to open source in
general is not about whether you use GitHub or a mailing list to throw
your stuff over the fence. It is about collaborating with the
community to find common ground between the various sometimes
conflicting interests, and permitting your engineers to engage with
the community.

Tianocore has always been a rather peculiar open source project, since
it wasn't more than just that, i.e., openly available source code.
This has been changing for the better during the time I have been
involved, and we have worked very hard with the Intel firmware team
and other contributors to collaborate better on the mailing list.

To summarize my concern here: it seems that this push is not about
making it easier for contributors that already know how to do open
source collaboration to contribute to Tianocore, it is about making it
easier for currently closed code to be contributed to Tianocore by
teams who have no prior experience with open source.

Apologies if I have the wrong end of the stick here. If not, why don't
we consult a few casual contributors (which should be easy to find on
the mailing list) and ask them what their biggest issues were with
contributing to Tianocore?






>
> -Original Message-
> From: edk2-devel  On Behalf Of stephano
> Sent: Friday, January 11, 2019 11:27 AM
> To: edk2-devel@lists.01.org
> Cc: Kin

Re: [edk2] [edk2-announce] Community Meeting Minutes

[Jeremiah Cox via edk2-devel]

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  On Behalf Of stephano
Sent: Friday, January 11, 2019 11:27 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 

Subject: [edk2] [edk2-announce] Community Meeting Minutes

An HTML version is available here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tianocore.org%2Fminutes%2FCommunity-2019-01.html&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=QuHaAW3%2Fw3lPV8JnHskquCRJ6VlVCDNV2rptymjvCFY%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=rECfPlMrOzcpi5GSCBEHUFmycKMA7gshN82bAPcXw0I%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=smcg%2B0hTO8oI3yVThCcnB1j8pRWA37XTLrqeNeE8vos%3D&reserved=0

Open Compute Project Global Summit
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opencompute.org%2Fsummit%2Fglobal-summit&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=gZpss9dmcJ7MqREcz%2FomaI8Un6157gM15%2FHTmOoOfyE%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C8998468d395f444243ed08d677fbe381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636828321081803213&sdata=2PGlE%2Faop%2Bw5A3gnhOJCO4S09FuLc4lc%2FNbIMtcdLog%3D&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 notifica

Re: [edk2] [edk2-announce][RFC] Collaboration Software: Microsoft Teams

[Jeremiah Cox via edk2-devel]

On the topic of Microsoft Teams, it has a free option, limited to 300 users.  
More than 300 users requires an enterprise license, starting at $8/user/month.  
There is a steep discount for some types of non-profits, but I don't know if we 
would qualify.

More details on the offering here:  
https://products.office.com/en-us/microsoft-teams/free

Highlights:
* Unlimited chat messages and search.
* Built-in audio and video calling for individuals, groups, and full team 
meetups.
* 10 GB of team file storage plus additional 2 GB per person for personal 
storage.
* Integrated, real-time content creation with Office Online apps, including 
built-in Word, Excel, PowerPoint, and OneNote.
* Unlimited app integrations with 140+ business apps to choose from-including 
Adobe, * Evernote, and Trello.
* Ability to communicate and collaborate with anyone inside or outside your 
organization, backed by Microsoft's secure, global infrastructure.

If this sounds like a viable option to the community, please email me and I'll 
add you as a guest on our Project Mu Teams channel for evaluation purposes.

Thanks,
Jeremiah

-Original Message-
From: edk2-devel  On Behalf Of stephano
Sent: Friday, November 16, 2018 8:59 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-announce][RFC] Collaboration Software

We are looking to augment our current communication methods (mailing list / 
IRC) with a modern solution for group collaboration. The goal is to allow folks 
to communicate effectively without interrupting the current patch review 
system, as well as enabling any future systems with more robust options.

Specific features we are looking for include attachments (currently blocked by 
the list), robust logging, modern chat, and integration with tools like bug 
trackers and source repositories (APIs, or better yet, pre-rolled plugins).

Our current contenders are Google Groups and Groups.io. This RFC is in hopes of 
finding other options to evaluate.

Cheers,
Stephano
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=02%7C01%7Cjerecox%40microsoft.com%7Ccced1ed304fa4bb2912508d64be60e56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636779848794152121&sdata=i3HtNOPFa010PWb2qSe4TKnTpsTwzPbQzN3S48uG9Po%3D&reserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Research Request

[Jeremiah Cox via edk2-devel]

Hi Laszlo,
Regarding "comprehensive backup/archival functionality that is core to the 
service itself", are you speaking more to GitHub's internal metadata verbosity 
(e.g. not losing PR details when branches and repos are deleted), GitHub's 
backup strategy to prevent data loss, or the ability to export all of this data 
from GitHub?

I believe your PR experiments are exploring the first point about metadata 
verbosity.  We've done some experimentation of our own and have found the 
verbosity acceptable for us.

GitHub's internal backup strategy is published:
https://help.github.com/articles/github-security/#file-system-and-backups 

Regarding export, I discovered GitHub has a preview REST API dedicated to 
backup & archival.  GitHub will package up all of our metadata into a big 
tarball:
https://developer.github.com/v3/migrations/orgs/ 
At a glance it appears to be simple to use and comprehensive.

I trust that any so called "web bugs" in GitHub emails are not malicious.  

Thanks,
Jeremiah

-Original Message-
From: Laszlo Ersek  
Sent: Tuesday, December 4, 2018 10:27 AM
To: Jeremiah Cox ; Brian J. Johnson 
; stephano 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce] Research Request

On 12/03/18 18:22, Jeremiah Cox wrote:
> Laszlo,
>
> Did you want to summarize your experience of our GitHub experiments?

That's right. I'll provide a summary below.

>  From your comments on the PRs, it sounded like the email  
> notifications did not provide the level of detail that you desire for  
> archival purposes.

That's correct.

> Stephano's email suggested that as long as we have an alternative 
> mechanism to archive all metadata, that may still be acceptable.

Indeed, that's what I think as well.

>  I propose that 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fjosegonzalez%2Fpython-github-backup&data=02%7C01%7Cjerecox
> %40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=OoS6nyB83BGn%2
> Bg%2BNnSA4AAsNqb3e6xjpHmR7LUvU98c%3D&reserved=0
>  may suffice.

I didn't miss it when you first recommended this utility, in:

  
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F2%23issuecomment-443066812&data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=edt3z5c7%2BDNTr%2BtkvHpUkEqCppG44B13WrvUkgPI0kY%3D&reserved=0

I didn't respond explicitly because, when you made that suggestion, I had 
already stated on the edk2-devel list that external tools that aren't a core 
part of the service wouldn't cut it, for me anyway:

  
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmid.mail-archive.com%2F76cb4d25-7eff-b19b-0dd5-2fcc3a1e7d82%40redhat.com&data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=L4eofdxURPR1HOy60ZcJW9KgE1ByPxIi09Y9slRbZ5w%3D&reserved=0

On 11/27/18 13:53, Laszlo Ersek wrote:
> GitHub has extremely good availability. I doubt that any hack we could 
> come up with (and that we'd have to run ourselves, elsewhere), could 
> muster the same service level. This means that sooner or later our 
> mirroring hack would go down, while GitHub would stay up, and then 
> we'd start losing updates to our "mirror".
>
> The offline & full coverage audit trail has to be generated by a core 
> part of the service.

I don't know who "josegonzalez" is, whom he works for, what his interests are, 
what kind of support we can get from him (for his software), where and how we 
should run his software, what SLA we could get from the organization that 
actually runs "python-github-backup" for us, and so on.

To repeat, it suffices if we get *at least one* of
(a) comprehensive email notifications,
(b) comprehensive backup/archival functionality that is core to the
service itself.

At this point, GitHub seems to provide zero of these.

(I'll also repeat that I agree that GitHub provides a *lot* of important and 
useful functionality in other areas. To me those areas are not
interchangeable.)

OK, so let me summarize my points, from:
- this thread,
- 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F1&data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=xFMUbMuuj6FKA2zPMrKZ0MlSHeDIhYc0LDYpMJj92wo%3D&reserved=0
- 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F2&data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=STndRd8YrVmWDTehLH2R7RlduAXmC7x6v%2FvgCxUR0%2BU%3D&reserved=0

On the plus side:

- It is possible to enable email notifications about one's own actions.

- It is 

Re: [edk2] [edk2-announce] Research Request

[Jeremiah Cox via edk2-devel]

Laszlo,

Did you want to summarize your experience of our GitHub experiments?  From your 
comments on the PRs, it sounded like the email notifications did not provide 
the level of detail that you desire for archival purposes.  Stephano’s email 
suggested that as long as we have an alternative mechanism to archive all 
metadata, that may still be acceptable.  I propose that 
https://github.com/josegonzalez/python-github-backup may suffice.



Thank you,

Jeremiah




From: Laszlo Ersek 
Sent: Thursday, November 29, 2018 1:48:18 AM
To: Jeremiah Cox; Brian J. Johnson; stephano
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce] Research Request

On 11/29/18 02:07, Jeremiah Cox wrote:
> I did a further experiment for you:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F2&data=02%7C01%7Cjerecox%40microsoft.com%7Cab0bcfaae8d14af6b1ba08d655dfcc78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790817039792972&sdata=ibzR7PEq%2FuT%2B4Q7ZTtDYow6sYKg%2B4Awj3cpFLD9vWhw%3D&reserved=0

Thanks!

> I cannot rebase away my history from PRs...
> Hopefully you have a nice email trail too.

The emails are coming in nice, but I'm not universally pleased with the
contents. I listed some issues regarding that in
,
 but I guess I should write them
up sometime more readably, at the end of this experiment.

Thanks!
Laszlo

> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, November 28, 2018 2:02 PM
> To: Jeremiah Cox ; Brian J. Johnson 
> ; stephano 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [edk2-announce] Research Request
>
> On 11/28/18 19:31, Jeremiah Cox wrote:
>> Test PR submitted
>
> Thanks!
> Laszlo
>

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Research Request

[Jeremiah Cox via edk2-devel]

I did a further experiment for you:
https://github.com/lersek/edk2/pull/2

I cannot rebase away my history from PRs...
Hopefully you have a nice email trail too.

-Original Message-
From: Laszlo Ersek  
Sent: Wednesday, November 28, 2018 2:02 PM
To: Jeremiah Cox ; Brian J. Johnson 
; stephano 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce] Research Request

On 11/28/18 19:31, Jeremiah Cox wrote:
> Test PR submitted

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Research Request

[Jeremiah Cox via edk2-devel]

Test PR submitted

-Original Message-
From: Laszlo Ersek  
Sent: Wednesday, November 28, 2018 3:07 AM
To: Brian J. Johnson ; Jeremiah Cox 
; stephano 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce] Research Request

On 11/27/18 22:55, Brian J. Johnson wrote:
> On 11/27/18 6:53 AM, Laszlo Ersek wrote:
>> On 11/26/18 22:43, Jeremiah Cox via edk2-devel wrote:
>>> Feedback on GitHub as follows…
>>>
>>>
>>>> 1. No Lock-In - What automated data export is available?
>>>> We want to be able to leave and take all our data with us. "Data" 
>>>> here
>>>> includes: review comments, pull requests / patches (including 
>>>> metadata), old (rejected) pull requests and metadata, issue tracker 
>>>> entries and comments (if issue tracker included). This archiving 
>>>> should be automated, not something we do by hand.
>>> Untested, but might these all be easily satisfied by subscribing a 
>>> mailing list to GitHub notifications?
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhel
>>> p.github.com%2Farticles%2Fabout-notifications%2F%23watching-notifica
>>> tions&data=02%7C01%7Cjerecox%40microsoft.com%7C86474d2516054fd63
>>> 42708d65521acec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367900
>>> 00471363695&sdata=19UcXzXaxWSI9Dwvj7Nb2p1TRa78H8nxgFznkLKYeOg%3D
>>> &reserved=0
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhel
>>> p.github.com%2Farticles%2Fabout-email-notifications%2F&data=02%7
>>> C01%7Cjerecox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C7
>>> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63679471363695&sda
>>> ta=ICXNdWhlzBzVfjKk5t5aBsMC6hY8onKZS1T3WqobERk%3D&reserved=0
>> No, they are insufficient.
>>
>> Following the last link above ("about-email-notifications"), one 
>> finds several other links; and one of those is:
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp
>> .github.com%2Farticles%2Fabout-notifications%2F&data=02%7C01%7Cje
>> recox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86
>> f141af91ab2d7cd011db47%7C1%7C0%7C63679471363695&sdata=C%2Fy1v
>> gLJC5cpL9fNQOqw1V28Omzazbu%2BeZC2m13wRLs%3D&reserved=0
>>
>> This article says,
>>
>>  GitHub sends participating notifications when you're directly
>>  involved in activities or conversations within a repository or a
>>  team you're a member of. You'll receive a notification when:
>>
>>  [...]
>>
>>  - You open, comment on, or close an issue or pull request.
>>
>>  [...]
>>
>> This is demonstrably false. I'm a member of the TianoCore 
>> organization, I have commented on, and closed (rejected):
>>
>>    
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> ub.com%2Ftianocore%2Fedk2%2Fpull%2F133&data=02%7C01%7Cjerecox%40m
>> icrosoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C63679471363695&sdata=BT0dw8IxXGiopl3%
>> 2FHfJl7w%2BGG8VSlEb2rvIetin5T2o%3D&reserved=0
>>
>> and I *never*  received an email notification about my *own*  comment 
>> / action. I only received the initial email, about the pull request 
>> being opened (attached for reference).
> 
> Try going to the "Settings" item under the menu in the top-right 
> corner, and clicking on the "Notifications" tab on the left.  Under 
> "Email notification preferences" there should be a checkbox for 
> "Include your own updates".  That may do what you need.

That did the trick. I checked the box and then went on to close PR#134.
I got two separate emails shortly after (attached), one about the closure and 
another about the comment.

In my opinion, the default value for the setting in question is broken (it 
should be "on" by default). However, to me anyway, it's a big plus for GitHub 
that it actually supports this feature. If we are going to adopt GitHub, then 
we can highlight the knob in our docs.

Regarding GitHub, what remains to be seen (for me) is if & how it preserves old 
(unmerged) topic branches, and review comments made for them, after the pull 
requestor rebases or deletes those branches in his/her repo.

Can someone please send an artificial/test PR against my personal repo, at 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2&data=02%7C01%7Cjerecox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63679471363695&sdata=ipRDM9x1QQnMSv7PF%2BE7yf3oGg7sBE3mjeqHw9vmyDA%3D&reserved=0>?
 Just change some lines in OvmfPkg/README or something like that.

Thank you!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Research Request

[Jeremiah Cox via edk2-devel]

There is a question of how the below is automated such that when there is a 
security advisory, a Phabricator instance is patched in a timely fashion.  
Perhaps there is a mailing list that would announce these and that could 
trigger an auto-update script.

It looks like Phabricator has publicly paid out 36 security bug bounties:
https://hackerone.com/phabricator/hacktivity?sort_type=latest_disclosable_activity_at&filter=type%3Abounty-awarded%20to%3Aphabricator&text_query=&page=1
 

-Original Message-
From: Rebecca Cran  
Sent: Tuesday, November 27, 2018 2:24 PM
To: edk2-devel@lists.01.org; Jeremiah Cox 
Cc: Knop, Ryszard ; stephano 

Subject: Re: [edk2] [edk2-announce] Research Request

On Tuesday, 27 November 2018 14:16:18 MST Jeremiah Cox via edk2-devel wrote:

> Do we have data on what it takes to deploy and operate Phabricator 
> with Harbormaster or Jenkins?  The up front development/deployment 
> activity/costs and then also the ongoing 
> patching/servicing/maintenance costs?  Is Intel planning to provide this?

I haven't integrated Harbormaster or Jenkins, but for just Phabricator the 
patching/servicing has ben really simple for the year+ I've been running it. 
I'd not consider it 'production' since I'm the only person using it and I'm 
running from Git master, not a stable branch - but maintenance has been as 
simple as the following (which could of course be put in a script to reduce the 
number of steps!):

# Stop the Phabricator daemon
./bin/phd stop
# Update Phabricator
git pull
# Update libphputil
cd ../libphputil && git pull
# Upgrade arcanist (commandline interface) cd ../arcanist && git pull # Upgrade 
database schema ./bin/storage upgrade # Start Phabricator daemon ./bin/phd 
start # Reload web server service nginx restart service php-fpm restart

The "storage upgrade" command goes through the database looking for any 
inconsistencies - missing keys, wrong data types etc., and offers to fix them.

--
Rebecca


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Research Request

[Jeremiah Cox via edk2-devel]

That is a good data point, thank you Ryszard.  

Do we have data on what it takes to deploy and operate Phabricator with 
Harbormaster or Jenkins?  The up front development/deployment activity/costs 
and then also the ongoing patching/servicing/maintenance costs?  Is Intel 
planning to provide this?

For Project Mu we are leveraging GitHub and Azure Dev Ops for gates & CI builds 
(free for OSS).  We had this basically working in a day and is operating for 
free with all patching/maintenance provided by GitHub & Azure Dev Ops.

-Original Message-
From: Knop, Ryszard  
Sent: Tuesday, November 27, 2018 1:34 AM
To: Jeremiah Cox ; stephano 
; edk2-devel@lists.01.org
Subject: RE: [edk2] [edk2-announce] Research Request

To add on Phabricator not supporting Travis CI - since Travis works exclusively 
with GitHub and has zero interest in supporting anything else, there are other 
options, eg Harbormaster ("native" CI module in Phabricator) or Jenkins (as far 
as I'm aware, many teams at Intel already know Jenkins one way or another). For 
a public example, KDE hosts all their sources on a self-hosted Phabricator 
instance and does CI with Jenkins - see 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuild.kde.org%2F&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&sdata=4coAaUQSgmoxLC3SDsW1M0X0bu61hhWQJlP%2B1xyP%2FW0%3D&reserved=0
 and 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphabricator.kde.org%2F&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&sdata=MJaEesRphYxAtZCSJ%2Fyz3ZwcT%2FmMBRGAYHL0GxD5KWw%3D&reserved=0
 - so that's not a problem :)

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeremiah 
Cox via edk2-devel
Sent: Monday, November 26, 2018 22:43
To: stephano 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce] Research Request

Feedback on GitHub as follows…


> 1. No Lock-In - What automated data export is available?
> We want to be able to leave and take all our data with us. "Data" here
> includes: review comments, pull requests / patches (including 
> metadata), old (rejected) pull requests and metadata, issue tracker 
> entries and comments (if issue tracker included). This archiving 
> should be automated, not something we do by hand.

Untested, but might these all be easily satisfied by subscribing a mailing list 
to GitHub notifications?  
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-notifications%2F%23watching-notifications&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&sdata=g3nvEWQuUZzFBEeEpSq63lZLRoPwp06el3kiNmFjfQA%3D&reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-email-notifications%2F&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&sdata=4k56B1IeZyK2f3d%2BX9D2q3FFpk0kHt4Jey1NlwYunzs%3D&reserved=0
 

Alternatively, the GitHub REST API appear to offer full export capability of 
all information & metadata:
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fgit%2Fcommits%2F%23get-a-commit&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=JsmAP23PWWpvjgfH9XO3qR0OtW8unBujs3MCG7ABCfg%3D&reserved=0
 
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fpulls%2F%23list-pull-requests&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=5TgHzyJNYI2YxRASb4z5QCtui100Ftz25tVxQObytrs%3D&reserved=0
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fpulls%2Fcomments%2F%23list-comments-on-a-pull-request&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=iDB1PW%2B9G1Ywjj%2FFeLYtKmcBI3szuz9%2FX5rBtL0ZNxk%3D&reserved=0
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fissues%2Fevents%2F%23list-events-for-a-repository&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=1lqC1ZUraFJqs8AJm0Ffd2pJGdK0lA2RA0ADteB2msQ%3D&reserved=0
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fissues%2F

Re: [edk2] [edk2-announce] Research Request

[Jeremiah Cox via edk2-devel]

Feedback on GitHub as follows…


> 1. No Lock-In - What automated data export is available?
> We want to be able to leave and take all our data with us. "Data" here 
> includes: review comments, pull requests / patches (including metadata), 
> old (rejected) pull requests and metadata, issue tracker entries and 
> comments (if issue tracker included). This archiving should be 
> automated, not something we do by hand.

Untested, but might these all be easily satisfied by subscribing a mailing list 
to GitHub notifications?  
https://help.github.com/articles/about-notifications/#watching-notifications 
https://help.github.com/articles/about-email-notifications/ 

Alternatively, the GitHub REST API appear to offer full export capability of 
all information & metadata:
   https://developer.github.com/v3/git/commits/#get-a-commit 
   https://developer.github.com/v3/pulls/#list-pull-requests
   
https://developer.github.com/v3/pulls/comments/#list-comments-on-a-pull-request
   https://developer.github.com/v3/issues/events/#list-events-for-a-repository
   https://developer.github.com/v3/issues/comments/#list-comments-on-an-issue 
   https://developer.github.com/v3/activity/events/#list-repository-events 
   
https://developer.github.com/v3/reactions/#list-reactions-for-a-pull-request-review-comment
 
   * the above allows you to export all of the thumbs up/down, smileys, hearts 
... that users have given to pull request & issue comments  :)



> 2. Easy Administration - Are there any scripts or custom code required 
> after initial setup? We would like to do as little customizing as possible.

Our interpretation of this bullet is to maximize developer productivity & 
minimize deployment & operations costs.  
GitHub provides a ready-to-use, end-to-end solution. There are no servers for 
end-customers to patch & maintain.
GitHub is free for use by open source projects, and Microsoft is committed to 
continuing this tradition:
https://www.microsoft.com/en-us/Investor/events/FY-2018/Microsoft-and-GitHub-Conference-Call
 
GitHub’s enormous user base has motivated numerous developers to generate 
GitHub Apps that further enhance the GitHub experience.  



> 3. Flexible Workflow - Can we use email patches / email review as well 
> as pull requests / web UI review?**
>   3a. Can we can attach review comments to specific code *and* commit 
> message locations?
>   3b. Are the comments faithfully translated to notification emails 
> (including the locations in code the comment is addressing)?
>   3c. Are old topic branches (rejected or updated pull requests) 
> available even after being rejected? (i.e. are they ever deleted?)
>   3d. Is plain text supported in code review comments?
> **To be clear, it is acceptable if the system handles only pull requests 
> and a web UI. We do require, however, a *read-only* email notification 
> system that thoroughly documents our process.

We propose that all review & issue tracking are through GitHub web, REST, or 
Graph APIs.  Email becomes read-only for notification and archival only.
3A:  Yes.
3B:  From our testing this appears to be yes.
3C:  GitHub can be configured to keep rejected and updated pull requests.  
3D:  Both plain text and markdown work



Some additional questions we feel are important:


*  Does the workflow facilitate automated validation & PR-Gates?  
GitHub: Yes
Phabricator:  https://secure.phabricator.com/T9456 : “Writing lots of 
integrations for third-party software is broadly something the upstream is not 
well equipped for.”
Travis-CI further declined support for Phabricator: 
https://github.com/travis-ci/travis-ci/issues/2143#issuecomment-124150608 “we 
have no immediate plans to add this feature”


*  Does workflow allow easy contribution process?  
GitHub:  Yes, well-known and well-documented


* Does it have comprehensive documentation?
GitHub:  Yes


*  Does it have a comprehensive programmatic API that enables extensibility, 
with numerous online examples?
GitHub:  Yes 


*  Does workflow facilitate different server-enforced policies for different 
branches?
GitHub:  Yes 



Sincerely,
Jeremiah Cox


-Original Message-
From: stephano  
Sent: Tuesday, November 20, 2018 4:59 PM
To: Jeremiah Cox 
Cc: edk2-devel@lists.01.org; Sean Brogan 
Subject: Re: [edk2] [edk2-announce] Research Request

Thank you both for taking the time to add some insight to our discussions. 
Please see the list of questions here:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fpipermail%2Fedk2-devel%2F2018-November%2F032462.html&data=02%7C01%7Cjerecox%40microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783587312509548&sdata=sra5nI19QTGmCbkDBeR7QYFTVpndqZqCjzkmhO0nlsU%3D&reserved=0

These are a summary from our community meetings.

Enjoy the holiday!

Cheers,
Stephano

On 11/20/2018 3:47 PM, Jeremiah Cox wrote:
> Hi Stephano,
> Sean and I will put something together for GitHub by next Tuesday

Re: [edk2] [edk2-announce] Research Request

[Jeremiah Cox via edk2-devel]

Hi Stephano,
Sean and I will put something together for GitHub by next Tuesday.  

Thank you,
Jeremiah Cox  (departing for Thanksgiving holiday... now...)

-Original Message-
From: edk2-devel  On Behalf Of stephano
Sent: Wednesday, November 14, 2018 10:34 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-announce] Research Request

We are currently researching several different options to help make 
contributing to TianoCore easier for the community. A big part of this effort 
will be enabling pull requests and allowing for a more customizable code review 
process.

I am looking for members of the community willing to answer a few questions 
about these solutions to allow us to evaluate our options quickly. The options 
are:

System/Tool Investigator
Phabricator Rebecca Cran (thank you again :) )
Github  ???
Gerrit  ???
Gitlab  ???

I have a list of questions that I can send out to each investigator. 
Assuming you are familiar with the software/system, these questions should be 
answerable with a couple hours of research, writing, and screenshots / examples.

Thanks in advance for your help!

-Stephano

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=02%7C01%7Cjerecox%40microsoft.com%7C9e286d6c4ed146e984f408d64a60f4e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636778177619451439&sdata=KhWxcMKtoC0Pm%2B2KvOLAoxxue4sFICLQBbALaAYX3o4%3D&reserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Core: correct one coding style

[Jeremiah Cox via edk2-devel]

Please ignore, testing DMARC issue

-Original Message-
From: edk2-devel  On Behalf Of Bi, Dandan
Sent: Friday, October 26, 2018 7:16 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: Re: [edk2] [PATCH] MdeModulePkg/Core: correct one coding style

Reviewed-by: Bi Dandan 

Thanks,
Dandan

> -Original Message-
> From: Wang, Jian J
> Sent: Saturday, October 27, 2018 10:13 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Zeng, Star 
> Subject: [PATCH] MdeModulePkg/Core: correct one coding style
> 
> REF: 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzi
> lla.tianocore.org%2Fshow_bug.cgi%3Fid%3D1284&data=02%7C01%7Cjereco
> x%40microsoft.com%7Cf845cc7305144d6fa26108d63bb232cd%7C72f988bf86f141a
> f91ab2d7cd011db47%7C1%7C0%7C636762033910771752&sdata=Dsl5pUhg5plef
> EERnF4LnU87wwY9XBkzz%2FIw8mlP%2FdU%3D&reserved=0
> 
> Non-Boolean comparisons should use a compare operator (==, !=, >, < 
> >=, <=)
> 
> Cc: Dandan Bi 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 521e0d7b2a..9f89df8d8f 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -1559,7 +1559,7 @@ PromoteGuardedFreePages (
>  }
>}
> 
> -  if (AvailablePages) {
> +  if (AvailablePages != 0) {
>  DEBUG ((DEBUG_INFO, "Promoted pages: %lX (%lx)\r\n", Start, 
> (UINT64)AvailablePages));
>  ClearGuardedMemoryBits (Start, AvailablePages);
> 
> --
> 2.19.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=02%7C01%7Cjerecox%40microsoft.com%7Cf845cc7305144d6fa26108d63bb232cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636762033910771752&sdata=c3FltaTxgnzeGkEnwF1dDBc4CGyWn19XuUjnHPrgC%2Fs%3D&reserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel