[edk2-announce] Research Request

[edk2-announce] Research Request

[stephano]

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

Re: [edk2-announce] Research Request

[Jeremiah Cox]

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 <edk2-devel-bounces@lists.01.org> 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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C9e286d6c4ed146e984f408d64a60f4e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636778177619451439&amp;sdata=KhWxcMKtoC0Pm%2B2KvOLAoxxue4sFICLQBbALaAYX3o4%3D&amp;reserved=0

Re: [edk2-announce] Research Request

[stephano]

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

https://lists.01.org/pipermail/edk2-devel/2018-November/032462.html

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.
> 
> Thank you,
> Jeremiah Cox  (departing for Thanksgiving holiday... now...)
> 
> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> 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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C9e286d6c4ed146e984f408d64a60f4e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636778177619451439&amp;sdata=KhWxcMKtoC0Pm%2B2KvOLAoxxue4sFICLQBbALaAYX3o4%3D&amp;reserved=0
> 

Re: [edk2-announce] Research Request

[Jeremiah Cox]

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 <stephano.cetola@linux.intel.com> 
Sent: Tuesday, November 20, 2018 4:59 PM
To: Jeremiah Cox <jerecox@microsoft.com>
Cc: edk2-devel@lists.01.org; Sean Brogan <sean.brogan@microsoft.com>
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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783587312509548&amp;sdata=sra5nI19QTGmCbkDBeR7QYFTVpndqZqCjzkmhO0nlsU%3D&amp;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.
> 
> Thank you,
> Jeremiah Cox  (departing for Thanksgiving holiday... now...)
> 
> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> 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&amp;data=02%7C01%7Cjerecox%4
> 0microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C636783587312509548&amp;sdata=SOR9cdCLwmsl37RB
> S0fkk6a%2FIE1so1flDYG2%2BzjCBbQ%3D&amp;reserved=0
> 

Re: [edk2-announce] Research Request

[stephano]

Excellent. Thank you for all your work here. I'll be compiling 
information regarding all our options on the wiki and we can further 
discuss them at our Community Meeting in December.

I'll share the link to the wiki post once it is live on this mailing list.

Cheers,
Stephano

On 11/26/2018 1:43 PM, Jeremiah Cox 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://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 <stephano.cetola@linux.intel.com>
> Sent: Tuesday, November 20, 2018 4:59 PM
> To: Jeremiah Cox <jerecox@microsoft.com>
> Cc: edk2-devel@lists.01.org; Sean Brogan <sean.brogan@microsoft.com>
> 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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783587312509548&amp;sdata=sra5nI19QTGmCbkDBeR7QYFTVpndqZqCjzkmhO0nlsU%3D&amp;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.
>>
>> Thank you,
>> Jeremiah Cox  (departing for Thanksgiving holiday... now...)
>>
>> -----Original Message-----
>> From: edk2-devel <edk2-devel-bounces@lists.01.org> 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&amp;data=02%7C01%7Cjerecox%4
>> 0microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C636783587312509548&amp;sdata=SOR9cdCLwmsl37RB
>> S0fkk6a%2FIE1so1flDYG2%2BzjCBbQ%3D&amp;reserved=0
>>

Re: [edk2-announce] Research Request

[Knop, Ryszard]

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://build.kde.org/ and https://phabricator.kde.org/ - so that's not a problem :)

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Jeremiah Cox via edk2-devel
Sent: Monday, November 26, 2018 22:43
To: stephano <stephano.cetola@linux.intel.com>
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://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 <stephano.cetola@linux.intel.com> 
Sent: Tuesday, November 20, 2018 4:59 PM
To: Jeremiah Cox <jerecox@microsoft.com>
Cc: edk2-devel@lists.01.org; Sean Brogan <sean.brogan@microsoft.com>
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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783587312509548&amp;sdata=sra5nI19QTGmCbkDBeR7QYFTVpndqZqCjzkmhO0nlsU%3D&amp;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.
> 
> Thank you,
> Jeremiah Cox  (departing for Thanksgiving holiday... now...)
> 
> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> 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&amp;data=02%7C01%7Cjerecox%4
> 0microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C636783587312509548&amp;sdata=SOR9cdCLwmsl37RB
> S0fkk6a%2FIE1so1flDYG2%2BzjCBbQ%3D&amp;reserved=0
> 
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

Re: [edk2-announce] Research Request

[Laszlo Ersek]

[-- Attachment #1: Type: text/plain, Size: 7127 bytes --]

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://help.github.com/articles/about-notifications/#watching-notifications 
> https://help.github.com/articles/about-email-notifications/ 

No, they are insufficient.

Following the last link above ("about-email-notifications"), one finds
several other links; and one of those is:

https://help.github.com/articles/about-notifications/

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://github.com/tianocore/edk2/pull/133

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

* Another pull request, demonstrating the same issue (original email
also attached):

  https://github.com/tianocore/edk2/pull/127

* And here's the same problem, just in a different situation: someone
made a comment on a commit, using the github WebUI:

https://github.com/tianocore/edk2/commit/253d81c71f67e1ab218450b87370abd3bf01d571#commitcomment-27830037

I responded there. I received an email -- attached -- only about that
other person's initial comment, and never received an email about my own.

So, no. I'm already subscribed to github notofications, and their
coverage is insufficient.

> 
> 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  :)

This is again insufficient. We shouldn't have to cobble together our own
archival soluion from low-level APIs.

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.

[...]

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

This sounds good, but can you please clarify 3C?

In particular, what does an "updated pull request" mean?

Here's the specific workflow I care about.

* Alice implements a new feature for edk2 and opens a pull request. The
pull request refers to her branch that is called "alices-grand-feature",
with the branch HEAD at commit FOO.

* Brenda reviews the commits on that branch, and makes some comments on
various patches:
- she attaches some requests for clarification to specific lines of some
commit messages (i.e., not code),
- she also attaches some suggestions to specific code lines.

* A few days later Alice comes back with the reworked patch set. In her
own repository, she rebased the "alices-grand-feature" branch, and now
the HEAD points at commit BAR. In Alice's own repository, the original
HEAD commit FOO is now lost (no branch references it). So are all the
commits on the original (v1) topic branch that used to lead up to FOO.

* Brenda gets an email notification that Alice refreshed her pull
request, with the remote topic branch -- which is offered under the same
name "alices-grand-feature" -- now pointing at commit BAR. Brenda has
since forgotten some of the comments she had made under v1, and now she
scrolls up to see the original v1 commits (culminating in FOO) from
Alice, and her own v1 comments.

GitHub supports this -- i.e., the complete git history leading up to
now-unreferenced commit FOO will be preserved for eternity, together
with all location-sensitive comments made for it -- because: [[please
fill in]].

> 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 

Right, those are good and important features.

Thanks,
Laszlo

[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 4184 bytes --]

From: Henri Yandell <notifications@github.com>
To: tianocore/edk2 <edk2@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: [tianocore/edk2] Adding missing 'or' (#133)
Date: Wed, 29 Aug 2018 22:31:49 -0700
Message-ID: <tianocore/edk2/pull/133@github.com>

When the CLA was created from the Apache ICLA, the option for a CCLA was removed. When this was done the 'or' was lost in the text. This puts it back in so that you represent that you have received permission __or__ your employer has waived such rights.
You can view, comment on, or merge this pull request online at:

  https://github.com/tianocore/edk2/pull/133

-- Commit Summary --

  * Adding missing 'or'

-- File Changes --

    M Contributions.txt (2)

-- Patch Links --

https://github.com/tianocore/edk2/pull/133.patch
https://github.com/tianocore/edk2/pull/133.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tianocore/edk2/pull/133

[-- Attachment #3: Attached Message --]
[-- Type: message/rfc822, Size: 3998 bytes --]

From: Anton Filatov <notifications@github.com>
To: tianocore/edk2 <edk2@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: [tianocore/edk2] Fix for Microsoft Visual Studio 2017 (#127)
Date: Wed, 06 Jun 2018 08:05:49 -0700
Message-ID: <tianocore/edk2/pull/127@github.com>

bin files for different architectures are now located in SDK version specific sub folder
You can view, comment on, or merge this pull request online at:

  https://github.com/tianocore/edk2/pull/127

-- Commit Summary --

  * Fix for Microsoft Visual Studio 2017

-- File Changes --

    M BaseTools/Conf/tools_def.template (2)

-- Patch Links --

https://github.com/tianocore/edk2/pull/127.patch
https://github.com/tianocore/edk2/pull/127.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tianocore/edk2/pull/127

[-- Attachment #4: Attached Message --]
[-- Type: message/rfc822, Size: 4237 bytes --]

From: 992548897 <notifications@github.com>
To: tianocore/edk2 <edk2@noreply.github.com>
Cc: Laszlo Ersek <lersek@redhat.com>,  Author <author@noreply.github.com>
Subject: Re: [tianocore/edk2] OvmfPkg: update -D E1000_ENABLE from Intel PROEFI v.07 to BootUtil v.22 (253d81c)
Date: Tue, 27 Feb 2018 22:13:32 -0800
Message-ID: <tianocore/edk2/commit/253d81c71f67e1ab218450b87370abd3bf01d571/27830037@github.com>

Hi, I'd learned that currently only 1024*768 resolution is supported for win7, however,  i'd like to know why and is there any plan for further support for other resolutions on win7 system.

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/tianocore/edk2/commit/253d81c71f67e1ab218450b87370abd3bf01d571#commitcomment-27830037

Re: [edk2-announce] Research Request

[Jeremiah Cox]

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 <ryszard.knop@intel.com> 
Sent: Tuesday, November 27, 2018 1:34 AM
To: Jeremiah Cox <jerecox@microsoft.com>; stephano <stephano.cetola@linux.intel.com>; 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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&amp;sdata=4coAaUQSgmoxLC3SDsW1M0X0bu61hhWQJlP%2B1xyP%2FW0%3D&amp;reserved=0 and https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphabricator.kde.org%2F&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&amp;sdata=MJaEesRphYxAtZCSJ%2Fyz3ZwcT%2FmMBRGAYHL0GxD5KWw%3D&amp;reserved=0 - so that's not a problem :)

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Jeremiah Cox via edk2-devel
Sent: Monday, November 26, 2018 22:43
To: stephano <stephano.cetola@linux.intel.com>
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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&amp;sdata=g3nvEWQuUZzFBEeEpSq63lZLRoPwp06el3kiNmFjfQA%3D&amp;reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-email-notifications%2F&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&amp;sdata=4k56B1IeZyK2f3d%2BX9D2q3FFpk0kHt4Jey1NlwYunzs%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=JsmAP23PWWpvjgfH9XO3qR0OtW8unBujs3MCG7ABCfg%3D&amp;reserved=0 
   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fpulls%2F%23list-pull-requests&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=5TgHzyJNYI2YxRASb4z5QCtui100Ftz25tVxQObytrs%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=iDB1PW%2B9G1Ywjj%2FFeLYtKmcBI3szuz9%2FX5rBtL0ZNxk%3D&amp;reserved=0
   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fissues%2Fevents%2F%23list-events-for-a-repository&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=1lqC1ZUraFJqs8AJm0Ffd2pJGdK0lA2RA0ADteB2msQ%3D&amp;reserved=0
   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fissues%2Fcomments%2F%23list-comments-on-an-issue&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=fzXJZ%2FQSLhhkAdkX5irJ6Kmu7ALwOBFXJ1J%2Fyp8hSFY%3D&amp;reserved=0 
   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Factivity%2Fevents%2F%23list-repository-events&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=SM1oYigZqo7hLhzpd9JC0ROmhy6mybhDsIUSVH7GBOU%3D&amp;reserved=0 
   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Freactions%2F%23list-reactions-for-a-pull-request-review-comment&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=qFB2gEBJvJ5AoQeCypTrtMIhqzDxm2mdpjXjknMiacE%3D&amp;reserved=0 
   * 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2FInvestor%2Fevents%2FFY-2018%2FMicrosoft-and-GitHub-Conference-Call&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=C1bH8GSrkJT%2FHyfVJ3z86TbjxGw%2FaFtYVX3sd%2FKzyOk%3D&amp;reserved=0
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.phabricator.com%2FT9456&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=8VcHl3KdEvHYJSuwjTSiCo74pzlw3VCBgbq%2FVwqeOUY%3D&amp;reserved=0 : “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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftravis-ci%2Ftravis-ci%2Fissues%2F2143%23issuecomment-124150608&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=7LfJbdjJUFip0NHCCYLOfoM%2BCD9%2FI%2FzOFC7yJQyknzQ%3D&amp;reserved=0 “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 <stephano.cetola@linux.intel.com>
Sent: Tuesday, November 20, 2018 4:59 PM
To: Jeremiah Cox <jerecox@microsoft.com>
Cc: edk2-devel@lists.01.org; Sean Brogan <sean.brogan@microsoft.com>
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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=JtgEwui0tzWoxOLH7YSqclJo4IJUgD5pmIm2u%2B%2B0j%2BY%3D&amp;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.
> 
> Thank you,
> Jeremiah Cox  (departing for Thanksgiving holiday... now...)
> 
> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> 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&amp;data=02%7C01%7Cjerecox%4
> 0microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C636783587312509548&amp;sdata=SOR9cdCLwmsl37RB
> S0fkk6a%2FIE1so1flDYG2%2BzjCBbQ%3D&amp;reserved=0
> 
_______________________________________________
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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&amp;sdata=t13IcLLPbGxmHxeQJAvs%2BrIoXbBk34KsJRUhIVPn010%3D&amp;reserved=0
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

Re: [edk2-announce] Research Request

[Brian J. Johnson]

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://help.github.com/articles/about-notifications/#watching-notifications  
>> https://help.github.com/articles/about-email-notifications/  
> No, they are insufficient.
> 
> Following the last link above ("about-email-notifications"), one finds
> several other links; and one of those is:
> 
> https://help.github.com/articles/about-notifications/
> 
> 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://github.com/tianocore/edk2/pull/133
> 
> 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.

-- 
Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

Re: [edk2-announce] Research Request

[Rebecca Cran]

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

Re: [edk2-announce] Research Request

[Desimone, Nathaniel L]

Hi Stephano,

If no one has claimed it yet I can take Gerrit.

Thanks,
Nate

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] 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://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2-announce] Research Request

[Stephano Cetola]

That would be great, thank you!

https://lists.01.org/pipermail/edk2-devel/2018-November/032462.html

Cheers,
Stephano
On Tue, Nov 27, 2018 at 9:54 PM Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com> wrote:
>
> Hi Stephano,
>
> If no one has claimed it yet I can take Gerrit.
>
> Thanks,
> Nate
>
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] 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://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2-announce] Research Request

[Laszlo Ersek]

[-- Attachment #1: Type: text/plain, Size: 2937 bytes --]

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://help.github.com/articles/about-notifications/#watching-notifications 
>>> https://help.github.com/articles/about-email-notifications/  
>> No, they are insufficient.
>>
>> Following the last link above ("about-email-notifications"), one finds
>> several other links; and one of those is:
>>
>> https://help.github.com/articles/about-notifications/
>>
>> 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://github.com/tianocore/edk2/pull/133
>>
>> 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://github.com/lersek/edk2>? Just change some lines in
OvmfPkg/README or something like that.

Thank you!
Laszlo

[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 3878 bytes --]

From: Laszlo Ersek <notifications@github.com>
To: tianocore/edk2 <edk2@noreply.github.com>
Cc: Laszlo Ersek <lersek@redhat.com>,  Your activity <your_activity@noreply.github.com>
Subject: Re: [tianocore/edk2] Compare to `None` using identity `is` operator (#134)
Date: Wed, 28 Nov 2018 02:41:15 -0800
Message-ID: <tianocore/edk2/pull/134/issue_event/1992063250@github.com>

Closed #134.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tianocore/edk2/pull/134#event-1992063250

[-- Attachment #3: Attached Message --]
[-- Type: message/rfc822, Size: 4680 bytes --]

From: Laszlo Ersek <notifications@github.com>
To: tianocore/edk2 <edk2@noreply.github.com>
Cc: Laszlo Ersek <lersek@redhat.com>,  Your activity <your_activity@noreply.github.com>
Subject: Re: [tianocore/edk2] Compare to `None` using identity `is` operator (#134)
Date: Wed, 28 Nov 2018 02:41:15 -0800
Message-ID: <tianocore/edk2/pull/134/c442401567@github.com>

Sorry about the late followup.

For now, please subscribe to the edk2-devel mailing list, and submit your patch as a normal git patch email, for review. https://lists.01.org/mailman/listinfo/edk2-devel

For now, I'm going to have to close this PR, but this action is entirely independent of the topic & quality of your patch. I encourage you to submit your patch to the list please.

The edk2 community is in the process of researching new methods to contribute, which many developers might find more convenient than the mailing list based workflow. Please refer to the wiki article at https://github.com/tianocore/tianocore.github.io/wiki/Community-Virtual-Meetings . Also, I recommend participating in the thread `[edk2] [edk2-announce] Research Request`. The archive is at https://lists.01.org/pipermail/edk2-devel/2018-November/032459.html .

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tianocore/edk2/pull/134#issuecomment-442401567

Re: [edk2-announce] Research Request

[Jeremiah Cox]

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 <rebecca@bluestop.org> 
Sent: Tuesday, November 27, 2018 2:24 PM
To: edk2-devel@lists.01.org; Jeremiah Cox <jerecox@microsoft.com>
Cc: Knop, Ryszard <ryszard.knop@intel.com>; stephano <stephano.cetola@linux.intel.com>
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

Re: [edk2-announce] Research Request

[Jeremiah Cox]

Test PR submitted

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com> 
Sent: Wednesday, November 28, 2018 3:07 AM
To: Brian J. Johnson <brian.johnson@hpe.com>; Jeremiah Cox <jerecox@microsoft.com>; stephano <stephano.cetola@linux.intel.com>
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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C86474d2516054fd63
>>> 42708d65521acec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367900
>>> 00471363695&amp;sdata=19UcXzXaxWSI9Dwvj7Nb2p1TRa78H8nxgFznkLKYeOg%3D
>>> &amp;reserved=0
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhel
>>> p.github.com%2Farticles%2Fabout-email-notifications%2F&amp;data=02%7
>>> C01%7Cjerecox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C7
>>> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790000471363695&amp;sda
>>> ta=ICXNdWhlzBzVfjKk5t5aBsMC6hY8onKZS1T3WqobERk%3D&amp;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&amp;data=02%7C01%7Cje
>> recox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86
>> f141af91ab2d7cd011db47%7C1%7C0%7C636790000471363695&amp;sdata=C%2Fy1v
>> gLJC5cpL9fNQOqw1V28Omzazbu%2BeZC2m13wRLs%3D&amp;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&amp;data=02%7C01%7Cjerecox%40m
>> icrosoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C636790000471363695&amp;sdata=BT0dw8IxXGiopl3%
>> 2FHfJl7w%2BGG8VSlEb2rvIetin5T2o%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790000471363695&amp;sdata=ipRDM9x1QQnMSv7PF%2BE7yf3oGg7sBE3mjeqHw9vmyDA%3D&amp;reserved=0>? Just change some lines in OvmfPkg/README or something like that.

Thank you!
Laszlo

Re: [edk2-announce] Research Request

[Rebecca Cran]

On Wednesday, 28 November 2018 11:19:33 MST Jeremiah Cox wrote:
> 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.

I'm not sure most people would like installations to be automatically updated 
without at least reviewing what such a script was going to do.

I agree someone would need to monitor for security advisories though, and 
schedule maintenance windows to update it.

-- 
Rebecca

Re: [edk2-announce] Research Request

[Laszlo Ersek]

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

Thanks!
Laszlo

Re: [edk2-announce] Research Request

[Jeremiah Cox]

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 <lersek@redhat.com> 
Sent: Wednesday, November 28, 2018 2:02 PM
To: Jeremiah Cox <jerecox@microsoft.com>; Brian J. Johnson <brian.johnson@hpe.com>; stephano <stephano.cetola@linux.intel.com>
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

Re: [edk2-announce] Research Request

[Laszlo Ersek]

On 11/29/18 02:07, Jeremiah Cox wrote:
> I did a further experiment for you:
> https://github.com/lersek/edk2/pull/2

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
<https://github.com/lersek/edk2/pull/1>, but I guess I should write them
up sometime more readably, at the end of this experiment.

Thanks!
Laszlo

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com> 
> Sent: Wednesday, November 28, 2018 2:02 PM
> To: Jeremiah Cox <jerecox@microsoft.com>; Brian J. Johnson <brian.johnson@hpe.com>; stephano <stephano.cetola@linux.intel.com>
> 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
> 

Re: [edk2-announce] Research Request

[Rebecca Cran]

Would you be interested in going through this process with Phabricator, too? 

Rebecca


On November 29, 2018 at 2:48:18 AM, Laszlo Ersek (lersek@redhat.com(mailto:lersek@redhat.com)) wrote:

> On 11/29/18 02:07, Jeremiah Cox wrote:
> > I did a further experiment for you:
> > https://github.com/lersek/edk2/pull/2
> 
> 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
> <https://github.com/lersek/edk2/pull/1>, but I guess I should write them
> up sometime more readably, at the end of this experiment.
> 
> Thanks!
> Laszlo
> 
> > -----Original Message-----
> > From: Laszlo Ersek <lersek@redhat.com>
> > Sent: Wednesday, November 28, 2018 2:02 PM
> > To: Jeremiah Cox <jerecox@microsoft.com>; Brian J. Johnson <brian.johnson@hpe.com>; stephano <stephano.cetola@linux.intel.com>
> > 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-announce] Research Request

[Laszlo Ersek]

On 11/29/18 22:20, Rebecca Cran wrote:
> Would you be interested in going through this process with Phabricator, too? 

Sure! Just tell me where to create an account.

Thanks,
Laszlo

> On November 29, 2018 at 2:48:18 AM, Laszlo Ersek (lersek@redhat.com(mailto:lersek@redhat.com)) wrote:
> 
>> On 11/29/18 02:07, Jeremiah Cox wrote:
>>> I did a further experiment for you:
>>> https://github.com/lersek/edk2/pull/2
>>
>> 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
>> <https://github.com/lersek/edk2/pull/1>, but I guess I should write them
>> up sometime more readably, at the end of this experiment.
>>
>> Thanks!
>> Laszlo
>>
>>> -----Original Message-----
>>> From: Laszlo Ersek <lersek@redhat.com>
>>> Sent: Wednesday, November 28, 2018 2:02 PM
>>> To: Jeremiah Cox <jerecox@microsoft.com>; Brian J. Johnson <brian.johnson@hpe.com>; stephano <stephano.cetola@linux.intel.com>
>>> 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-announce] Research Request

[Jeremiah Cox]

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 <lersek@redhat.com>
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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Cab0bcfaae8d14af6b1ba08d655dfcc78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790817039792972&amp;sdata=ibzR7PEq%2FuT%2B4Q7ZTtDYow6sYKg%2B4Awj3cpFLD9vWhw%3D&amp;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
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F1&amp;data=02%7C01%7Cjerecox%40microsoft.com%7Cab0bcfaae8d14af6b1ba08d655dfcc78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790817039792972&amp;sdata=TcCYyatJSFplDFHNeTp34BpG4d3%2FSA28NIMPCpyQCwQ%3D&amp;reserved=0>, but I guess I should write them
up sometime more readably, at the end of this experiment.

Thanks!
Laszlo

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Wednesday, November 28, 2018 2:02 PM
> To: Jeremiah Cox <jerecox@microsoft.com>; Brian J. Johnson <brian.johnson@hpe.com>; stephano <stephano.cetola@linux.intel.com>
> 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
>

Re: [edk2-announce] Research Request

[Rebecca Cran]

On Monday, 3 December 2018 02:29:28 MST Laszlo Ersek wrote:
> On 11/29/18 22:20, Rebecca Cran wrote:
> > Would you be interested in going through this process with Phabricator,
> > too?
> Sure! Just tell me where to create an account.

Go to https://code.bluestop.org/auth/register/ to create a new account on the 
system, or https://code.bluestop.org/auth/ to login using an existing GitHub 
account.

- -
Rebecca

Re: [edk2-announce] Research Request

[Laszlo Ersek]

Hi Rebecca,

On 12/03/18 22:39, Rebecca Cran wrote:
> On Monday, 3 December 2018 02:29:28 MST Laszlo Ersek wrote:
>> On 11/29/18 22:20, Rebecca Cran wrote:
>>> Would you be interested in going through this process with Phabricator,
>>> too?
>> Sure! Just tell me where to create an account.
> 
> Go to https://code.bluestop.org/auth/register/ to create a new account on the 
> system, or https://code.bluestop.org/auth/ to login using an existing GitHub 
> account.

This is just a quick note to confirm that I've now tagged this for
later. I hope to follow up later this week. (My apologies, I ran out of
time/steam today -- exploration like this requires a fresh mind.)

Thanks!
Laszlo

Re: [edk2-announce] Research Request

[Philippe Mathieu-Daudé]

Hi Stephano,

On 14/11/18 19:34, stephano wrote:
> 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.

I'll run your checklist [*] with GitLab on Thursday.

[*] https://lists.01.org/pipermail/edk2-devel/2018-November/032462.html

> 
> Thanks in advance for your help!
> 
> -Stephano
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2-announce] Research Request

[Laszlo Ersek]

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://github.com/josegonzalez/python-github-backup
>  may suffice.

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

  https://github.com/lersek/edk2/pull/2#issuecomment-443066812

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:

  http://mid.mail-archive.com/76cb4d25-7eff-b19b-0dd5-2fcc3a1e7d82@redhat.com

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://github.com/lersek/edk2/pull/1
- https://github.com/lersek/edk2/pull/2

On the plus side:

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

- It is possible to attach comments to specific lines of a patch.

- The "commits" button at the top gives a complete view, with subject
  line, commit message, code, and (optionally) review comments
  displayed.

- Rejecting a pull request does not make the HEAD of the proposed topic
  branch disappear; the commit reference from the PR keeps working.

- This remains true even if the originator (pull requester) repository
  is removed.

On the minus side:

- I couldn't attach comments to the commit message (in particular to
  specific lines of the commit message). As a stop-gap measure, I could
  make a general comment and refer to the commit message.

- When making a comment on a patch, it is unclear how "add single
  comment" differs from "start a review".

- Email notifications lack context. The notification does not name the
  commit (the subject line of the patch is not quoted, just the title of
  the PR), which is a problem if a series consists of multiple patches.
  In addition, trailing code context (that follows the review comment
  being sent out in email) is not cited in the email, only the preceding
  code context is. The commit message is also not quoted in the email.

- The email notifications contain "web bugs". My MUA warns that it
  blocks remote content while displaying these emails. The emails should
  be self-contained.

- Some questions remain unanswered about longevity of PR branches whose
  originating repos disappear:

  - How can a CLI user fetch the orphaned branch into a local clone of
    his/hers? The GitHub WebUI does not provide a "remote URL" for this.

  - Do such branches survive "git gc" (garbage collection) that GitHub
    surely runs periodically?

  - What happens if not only the originating repo is deleted, but the
    pull requestor's user account too?

I don't insist that others agree with me that these are "minuses"; I'm
expressing my personal impressions. Furthermore, I have no idea at all
whether other web-based development tools perform better in these areas.

Thanks!
Laszlo

Re: [edk2-announce] Research Request

[Laszlo Ersek]

On 12/03/18 22:39, Rebecca Cran wrote:
> On Monday, 3 December 2018 02:29:28 MST Laszlo Ersek wrote:
>> On 11/29/18 22:20, Rebecca Cran wrote:
>>> Would you be interested in going through this process with Phabricator,
>>> too?
>> Sure! Just tell me where to create an account.
> 
> Go to https://code.bluestop.org/auth/register/ to create a new account on the 
> system, or https://code.bluestop.org/auth/ to login using an existing GitHub 
> account.

Thanks, I've got an account now.

Can you assist with the following please?

(1) Pls. explain to me how I can create an edk2 clone at
<code.bluestop.org>. :)

(2) Please create a throw-away account for yourself.

(3) Submit a pullreq against (1), with a topic branch that has two
commits, and simple text file modifications.

(4) I should then "review" these patches.

(5) Please rebase the same topic branch from (3), with "fixes" from (4),
and refresh the pull request.

(6) I should check whether the old topic branch (version) is still
available. Both on the web (including the original review comments, from
(4)), and for local fetching.

(7) Please delete the user account from (2). I should re-check (6).

(8) Meanwhile I should keep an eye on the email notifications, as to how
detailed / context-ful they are.

Thanks!
Laszlo

Re: [edk2-announce] Research Request

[stephano]

On 12/4/2018 10:20 AM, Philippe Mathieu-Daudé wrote:
> Hi Stephano,
> 
> 
> I'll run your checklist [*] with GitLab on Thursday.
> 

Perfect, thank you Philippe.

Cheers,
Stephano

Re: [edk2-announce] Research Request

[Rebecca Cran]

On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:

> (1) Pls. explain to me how I can create an edk2 clone at
> <code.bluestop.org>. :)

You don't. In a production system it may be possible to clone from either 
GitHub or code.bluestop.org (which mirrors github), but the clone URL given 
when you click "Clone" on https://code.bluestop.org/diffusion/EDK/ doesn't 
work (since I've not configured it).
 
> (2) Please create a throw-away account for yourself.

Done (though not throw-away).
 
> (3) Submit a pullreq against (1), with a topic branch that has two
> commits, and simple text file modifications.

https://code.bluestop.org/D1
Since Phabricator doesn't care about topic branches (just patches), I created 
a diff to README.

-- 
Rebecca

Re: [edk2-announce] Research Request

[Rebecca Cran]

On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:

> Can you assist with the following please?

Also, a couple of notes:

Go to https://code.bluestop.org/settings/user/lersek/  to configure preferences 
related to emails (http/plain), diffs etc.

Install the arcanist package on your system or follow the instructions at 
https://secure.phabricator.com/book/phabricator/article/arcanist/#installing-arcanist to get a copy (the 'arc' command). It's the command-line interface to 
Phabricator.

https://code.bluestop.org/differential/ is your main code reviews page.
https://code.bluestop.org/diffusion/ is a repo browser.
https://code.bluestop.org/maniphest/ (if we were to use it) is for tasks and 
bugs.

-- 
Rebecca

Re: [edk2-announce] Research Request

[Jeremiah Cox]

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 <lersek@redhat.com> 
Sent: Tuesday, December 4, 2018 10:27 AM
To: Jeremiah Cox <jerecox@microsoft.com>; Brian J. Johnson <brian.johnson@hpe.com>; stephano <stephano.cetola@linux.intel.com>
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&amp;data=02%7C01%7Cjerecox
> %40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636795448114734464&amp;sdata=OoS6nyB83BGn%2
> Bg%2BNnSA4AAsNqb3e6xjpHmR7LUvU98c%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&amp;sdata=edt3z5c7%2BDNTr%2BtkvHpUkEqCppG44B13WrvUkgPI0kY%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&amp;sdata=L4eofdxURPR1HOy60ZcJW9KgE1ByPxIi09Y9slRbZ5w%3D&amp;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&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&amp;sdata=xFMUbMuuj6FKA2zPMrKZ0MlSHeDIhYc0LDYpMJj92wo%3D&amp;reserved=0
- https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F2&amp;data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&amp;sdata=STndRd8YrVmWDTehLH2R7RlduAXmC7x6v%2FvgCxUR0%2BU%3D&amp;reserved=0

On the plus side:

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

- It is possible to attach comments to specific lines of a patch.

- The "commits" button at the top gives a complete view, with subject
  line, commit message, code, and (optionally) review comments
  displayed.

- Rejecting a pull request does not make the HEAD of the proposed topic
  branch disappear; the commit reference from the PR keeps working.

- This remains true even if the originator (pull requester) repository
  is removed.

On the minus side:

- I couldn't attach comments to the commit message (in particular to
  specific lines of the commit message). As a stop-gap measure, I could
  make a general comment and refer to the commit message.

- When making a comment on a patch, it is unclear how "add single
  comment" differs from "start a review".

- Email notifications lack context. The notification does not name the
  commit (the subject line of the patch is not quoted, just the title of
  the PR), which is a problem if a series consists of multiple patches.
  In addition, trailing code context (that follows the review comment
  being sent out in email) is not cited in the email, only the preceding
  code context is. The commit message is also not quoted in the email.

- The email notifications contain "web bugs". My MUA warns that it
  blocks remote content while displaying these emails. The emails should
  be self-contained.

- Some questions remain unanswered about longevity of PR branches whose
  originating repos disappear:

  - How can a CLI user fetch the orphaned branch into a local clone of
    his/hers? The GitHub WebUI does not provide a "remote URL" for this.

  - Do such branches survive "git gc" (garbage collection) that GitHub
    surely runs periodically?

  - What happens if not only the originating repo is deleted, but the
    pull requestor's user account too?

I don't insist that others agree with me that these are "minuses"; I'm expressing my personal impressions. Furthermore, I have no idea at all whether other web-based development tools perform better in these areas.

Thanks!
Laszlo

Re: [edk2-announce] Research Request

[Laszlo Ersek]

On 12/05/18 20:09, Jeremiah Cox wrote:
> 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?

The last one.

Unless the service sends sufficiently comprehensive emails, so that a
human reader -- note: not writer -- can later get a full understanding
of the events related to the project, the service should provide some
other (core) functionality to keep an external archive up-to-date at all
times. The goal of both alternatives is the same -- at any point, if the
service suddenly becomes unusable, the project should be at liberty to
take its past with itself elsewhere. At that point, extracting data may
no longer be possible, which is why the archive should continuously be
refreshed, on-line.

> I believe your PR experiments are exploring the first point about metadata verbosity.

Not exactly / not only. I care about multiple topics. One is the
usability of the WebUI itself (e.g. what artifacts one can attach review
comments to). Another is the longevity of artifacts as they are
presented on the WebUI (and to local git command lines). Yet another is
how independent a project can remain / how easily it can take its past
with itself elsewhere. Others have mentioned offline reviewing of
project events (recent or not so recent).

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

If this archive is complete (that is, if we download it on Monday, fail
to download it on Tuesday, manage to download it again on Wednesday, and
the Wed download contains all the Tues events as well), then I agree it
is comprehensive enough, because outages in the consumer component will
not cause permanent data loss -- eventually the next successful download
will fill the gap.

I'm unsure about the scope of this feature however. The page you linked
starts with:

    The organization migrations API lets you move a repository from
    GitHub to GitHub Enterprise.

That's not really what I have in mind; instead, if the above
(comprehensive) download is offered indeed, we should download it daily.
That would sort-of cover alternative #2.

Thanks
Laszlo

Re: [edk2-announce] Research Request

[Laszlo Ersek]

On 12/05/18 18:31, Rebecca Cran wrote:
> On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
> 
>> Can you assist with the following please?
> 
> Also, a couple of notes:
> 
> Go to https://code.bluestop.org/settings/user/lersek/  to configure preferences 
> related to emails (http/plain), diffs etc.
> 
> Install the arcanist package on your system or follow the instructions at 
> https://secure.phabricator.com/book/phabricator/article/arcanist/#installing-arcanist to get a copy (the 'arc' command). It's the command-line interface to 
> Phabricator.

That's optional, right? It's OK if it improves interaction with
Phabricator, but hopefully it shouldn't be a hard requirement.

(It seems that arcanist is not packaged for Fedora -- I don't see builds
in Koji past Fedora 25:
<https://koji.fedoraproject.org/koji/packageinfo?packageID=23387>

and the Review Request RHBZ at
<https://bugzilla.redhat.com/show_bug.cgi?id=1362487> is still "ASSIGNED".)

> 
> https://code.bluestop.org/differential/ is your main code reviews page.
> https://code.bluestop.org/diffusion/ is a repo browser.
> https://code.bluestop.org/maniphest/ (if we were to use it) is for tasks and 
> bugs.
> 

Thanks,
Laszlo

Re: [edk2-announce] Research Request

[Laszlo Ersek]

On 12/05/18 18:26, Rebecca Cran wrote:
> On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
> 
>> (1) Pls. explain to me how I can create an edk2 clone at
>> <code.bluestop.org>. :)
> 
> You don't. In a production system it may be possible to clone from either 
> GitHub or code.bluestop.org (which mirrors github), but the clone URL given 
> when you click "Clone" on https://code.bluestop.org/diffusion/EDK/ doesn't 
> work (since I've not configured it).

Well, I don't specifically desire creating an edk2 clone on
<code.bluestop.org> *using the WebUI*. However, in order to share my
work (i.e. to submit a pull request that refers to a topic branch of
mine), I need to have a publicly available / fetchable git repository.
(This is no different from mailing list based pull requests BTW.)

So, let me reformulate: can I *have* (by any means) a personal edk2
clone on <code.bluestop.org>, and can I push my topic branches there?
(Obviously it's not specifically about me nor specifically about
<code.bluestop.org>, but about any contributor with a topic branch to
submit, and about any site that would possibly run the central edk2
Phabricator instance.)

Right now I'm confused whether Phabricator (in general) offers
repository storage for contributors, or if that would have to come from
another service. (That wouldn't be too convenient.)

Anyway, the goal of a personal edk2 repo (clone) for me on
<code.bluestop.org> would be that I should be able to receive pull
requests against it.

Am I misunderstanding something?

>  
>> (2) Please create a throw-away account for yourself.
> 
> Done (though not throw-away).

I suggested "throw-away" because one of the later steps involves
deleting it.

>  
>> (3) Submit a pullreq against (1), with a topic branch that has two
>> commits, and simple text file modifications.
> 
> https://code.bluestop.org/D1
> Since Phabricator doesn't care about topic branches (just patches),

Please wait a second, I don't understand. What do you mean by "doesn't
care about topic branches, just patches"?

Compare three scenarios:

(a) Someone implements a new feature in 10 patches, and sends each patch
individually to the mailing list, without a common cover letter, and
without numbering in the subject lines. That's what I'd call "doesn't
care about branches just patches", and it's unusable for development.

(b) Someone sends a normal patch series, they just don't state what
upstream commit the series applies to. I can sort-of see this as "no
topic branch, just patches". Is this what you mean? Does Phabricator
maintain the series of patches as such (without a base commit), i.e. the
set of patches in the series, and their relative order?

(c) An actual pull request that refers to a specific commit hash (which
may or may not, although it almost always is, identified by a branch
head or tag).

Thanks,
Laszlo

> I created a diff to README.
> 

Re: [edk2-announce] Research Request

[Laszlo Ersek]

On 12/06/18 15:05, Laszlo Ersek wrote:
> On 12/05/18 18:26, Rebecca Cran wrote:
>> On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
>>
>>> (1) Pls. explain to me how I can create an edk2 clone at
>>> <code.bluestop.org>. :)
>>
>> You don't. In a production system it may be possible to clone from either 
>> GitHub or code.bluestop.org (which mirrors github), but the clone URL given 
>> when you click "Clone" on https://code.bluestop.org/diffusion/EDK/ doesn't 
>> work (since I've not configured it).
> 
> Well, I don't specifically desire creating an edk2 clone on
> <code.bluestop.org> *using the WebUI*. However, in order to share my
> work (i.e. to submit a pull request that refers to a topic branch of
> mine), I need to have a publicly available / fetchable git repository.
> (This is no different from mailing list based pull requests BTW.)
> 
> So, let me reformulate: can I *have* (by any means) a personal edk2
> clone on <code.bluestop.org>, and can I push my topic branches there?
> (Obviously it's not specifically about me nor specifically about
> <code.bluestop.org>, but about any contributor with a topic branch to
> submit, and about any site that would possibly run the central edk2
> Phabricator instance.)
> 
> Right now I'm confused whether Phabricator (in general) offers
> repository storage for contributors, or if that would have to come from
> another service. (That wouldn't be too convenient.)
> 
> Anyway, the goal of a personal edk2 repo (clone) for me on
> <code.bluestop.org> would be that I should be able to receive pull
> requests against it.
> 
> Am I misunderstanding something?
> 
>>  
>>> (2) Please create a throw-away account for yourself.
>>
>> Done (though not throw-away).
> 
> I suggested "throw-away" because one of the later steps involves
> deleting it.
> 
>>  
>>> (3) Submit a pullreq against (1), with a topic branch that has two
>>> commits, and simple text file modifications.
>>
>> https://code.bluestop.org/D1
>> Since Phabricator doesn't care about topic branches (just patches),
> 
> Please wait a second, I don't understand. What do you mean by "doesn't
> care about topic branches, just patches"?
> 
> Compare three scenarios:
> 
> (a) Someone implements a new feature in 10 patches, and sends each patch
> individually to the mailing list, without a common cover letter, and
> without numbering in the subject lines. That's what I'd call "doesn't
> care about branches just patches", and it's unusable for development.
> 
> (b) Someone sends a normal patch series, they just don't state what
> upstream commit the series applies to. I can sort-of see this as "no
> topic branch, just patches". Is this what you mean? Does Phabricator
> maintain the series of patches as such (without a base commit), i.e. the
> set of patches in the series, and their relative order?
> 
> (c) An actual pull request that refers to a specific commit hash (which
> may or may not, although it almost always is, identified by a branch
> head or tag).

Sigh, I failed to finish (c). I meant to ask, assuming I upload my work
(a topic branch) via git-push to the phabricator instance that hosts my
personal clone -- when I submit the pull request, does the pull req
preserve the specific commit hash (and hence the full git history
leading up to it), or does the request decay to (b), similarly to the
"normal" mailing list posting?

Thanks,
Laszlo

Re: [edk2-announce] Research Request

[Laszlo Ersek]

On 12/05/18 18:26, Rebecca Cran wrote:
> On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
> 
>> (1) Pls. explain to me how I can create an edk2 clone at
>> <code.bluestop.org>. :)
> 
> You don't. In a production system it may be possible to clone from either 
> GitHub or code.bluestop.org (which mirrors github), but the clone URL given 
> when you click "Clone" on https://code.bluestop.org/diffusion/EDK/ doesn't 
> work (since I've not configured it).
>  
>> (2) Please create a throw-away account for yourself.
> 
> Done (though not throw-away).
>  
>> (3) Submit a pullreq against (1), with a topic branch that has two
>> commits, and simple text file modifications.
> 
> https://code.bluestop.org/D1
> Since Phabricator doesn't care about topic branches (just patches), I created 
> a diff to README.
> 

(Sorry about the many emails I'm sending. :/ )

I've just noticed that I got the following emails:

  [Differential] [Request] [+      ] D1: Update URL of OVMF page
  [Differential] [Updated] D1: Update URL of OVMF page

They don't contain any code (diff hunks). I hope I can change that in my
email preferences (I haven't gotten around checking those yet). However,
one bit that I doubt I'll be able to update myself, is the sender for
these emails:

  noreply@phabricator.example.com

That doesn't look right even for this testing; can you please update the
config? I believe the emails should come from a sender @
code.bluestop.org. Is that correct?

Thanks,
Laszlo

Re: [edk2-announce] Research Request

[Rebecca Cran]

On December 6, 2018 at 7:13:24 AM, Laszlo Ersek (lersek@redhat.com(mailto:lersek@redhat.com)) wrote:

> I've just noticed that I got the following emails:
>  
> [Differential] [Request] [+ ] D1: Update URL of OVMF page
> [Differential] [Updated] D1: Update URL of OVMF page
>  
> They don't contain any code (diff hunks). I hope I can change that in my
> email preferences (I haven't gotten around checking those yet). However,
> one bit that I doubt I'll be able to update myself, is the sender for
> these emails:
>  
> noreply@phabricator.example.com  

Yeah, sorry - I’ll fix the configuration this evening to send diffs and allow replies to emails (and update the domain name).






Rebecca

Re: [edk2-announce] Research Request

[Rebecca Cran]

On Thursday, 6 December 2018 07:13:24 MST Laszlo Ersek wrote:

> They don't contain any code (diff hunks). I hope I can change that in my
> email preferences (I haven't gotten around checking those yet). 

I've updated the Mail settings to inline diffs up to 200 lines, and also 
attach diffs to the emails. It sends git-style diffs - it can also be 
configured to send unified diffs instead.

>   noreply@phabricator.example.com
> 
> That doesn't look right even for this testing; can you please update the
> config? I believe the emails should come from a sender @
> code.bluestop.org. Is that correct?

I've configured it to send from phab@bluestop.org .

I'm sure there are other things that aren't properly configured (for example, 
I've not set it up so you can reply to emails and have those replies be added 
to the review), but hopefully it gives you an idea of what it can do.

-- 
Rebecca

my Phabricator findings [was: Research Request]

[Laszlo Ersek]

Hi,

I'd like to conclude my Phabricator investigation now. Indeed I have
spent a lot less time on it than on GitHub, however my reason for this
earlier finish is not bias or exhaustion. I believe to have found some
pretty critical functionality gaps in Phabricator, which make it
"secondary" how the emails it sends look and such.

(The URLs we used for investigation are:

https://code.bluestop.org/D1
https://code.bluestop.org/D2
https://code.bluestop.org/D3
https://code.bluestop.org/D4
)

Namely: Phabricator doesn't integrate natively with git topic branches,
or with "git" itself, for that matter.

Submitting a series of commits (a topic branch) for review seems to
require a tool called "arcanist" (or "arc" for short), which from my
perspective is a very unwelcome requirement. (Earlier I expressed my
hope that it would be an optional tool.) Rebecca pointed me to the
following article:

  https://smacleod.ca/posts/commit-series-with-phabricator/

and while the method described might technically work, I think it's a
large step back in usability if we need to dance around the system with
an extra tool (which isn't even packaged by several Linux distributions
currently), just for submitting a topic branch for review.

In addition, the way a commit series is represented in a Phabricator
(for the purposes of comprehensive review), AIUI, is a chain of
inter-dependent, but *separate* review requests. While the article above
describes a method for interleaving a local "git rebase -i" procedure
with re-stacking the patches / review requests on the Phabricator
server, it strongly feels like a workaround for a system for which a
*series* of patches is only an afterthought, not the core idea. (In git,
branches are the core idea -- creating them is very cheap, and merging
them is actually possible.)

In other words, even though setting up the local commit messages as
required by Phabricator, and running "arc diff" in a loop basically,
might obviate a manual struggle on the WebUI, for stacking multiple
review requests (one per patch) into a series, I don't see how it could
work in any sensible way with the size of the patch sets that we
regularly post. 10-20 patches in an edk2 series are totally normal, and
50+ patches in a series are not unheard of.

Yes, 50+ patches in a series are not frequent, but long series are
*exactly* when you need your tooling to support you the most. I can't
see myself integrating an external tool with "git rebase" (esp. one that
might call out over the network, such as "arc diff") when I'm trying to
move code hunks between patches in a 20+ part series.

When polishing a large series, it's not uncommon to rebase the whole
thing multiple tens of times.

Yet further, according to Rebecca's explanation in
<https://code.bluestop.org/D1>, fetching a patch under review for local
testing again requires "arc". This is not native to git, and I think it
causes more problems than it solves.

Also, what about fetching a series of patches, i.e. a series of
dependent review requests... The local git command line works *already*
(once we're given a remote URL and a branch or tag), so let's not mess
with that please.

To be honest, I'm stumped how Mozilla could adopt (according to the
article linked at the top) "Phabricator as the primary code review
system for Firefox".

Out of this exercise, I'd like to suggest a hard requirement for all
future candidates: native integration with "git" is a must, and the
system must not require additional command line tools for basic git
operations (such as push, fetch, rebase), and basic participation in
development.

Thanks,
Laszlo

Re: my Phabricator findings [was: Research Request]

[Rebecca Cran]

On December 7, 2018 at 5:00:55 AM, Laszlo Ersek (lersek@redhat.com(mailto:lersek@redhat.com)) wrote:

> To be honest, I'm stumped how Mozilla could adopt (according to the
> article linked at the top) "Phabricator as the primary code review
> system for Firefox".  

They previously used Review Board (https://www.reviewboard.org/), which similarly uses a tool ‘rbt’ (RB Tools) to post/manage reviews, so it seems their processes are set up to work in such a way.


I can understand that our workflow is different and not a good fit for the model Phabricator uses.






Rebecca

GitLab results from my POV [was: Research Request]

[Laszlo Ersek]

Hi,

On 11/14/18 19:34, stephano wrote:
> 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!

So Phil and I worked on evaluating GitLab. Phil opened a merge request
(MR#2) at <https://gitlab.com/philmd/edk2-platforms/merge_requests/2>,
and we used that for the evaluation. It was a multi-patch series. Here's
how it went.

(1) I couldn't make comments tied to the commit messages of the patches.
I could make generic comments on the merge request itself. I could also
make code location-tied comments on the individual commits. So this was
a mixed result.

(2) The WebUI is incredibly resource hungry, in my Firefox setup anyway.
Even while just scrolling the diffs with the mouse wheel, one CPU of my
laptop was pegged at 100%, and the visual response lagged *hugely* after
my manual mouse actions. This affected "alt text" displays for icons,
and clicking icons/buttons as well. It was so annoying it made me *not*
want to look at the subject patch set at all, just so I could stop
dealing with the UI.

(3) I managed to figure out a way for fetching the topic branch that was
pending review / the merge request. So that was good.

(4) Once Phil force-pushed a non-ff update, the old branch head was lost
in the sense that (a) it was apparently no longer "named" by anything,
(b) I could no longer refer to the v1 history on a commit-by-commit
basis, only as a cumulative diff. First, I could only compare the
cumulative diffs between v1 and v2. Second, my v1 comments lost their
contexts -- they were displayed near the code snippets where I had made
them, but they were no longer connected to individual commits. I found
this extremely confusing -- basically, the commit boundaries and the
discussion contexts were lost for v1.

(5) I received *zero* emails about my own actions, and I couldn't figure
out where I could change that. (In GitHub at least there's an obscure
setting that can be toggled -- Brian Johnson told me about that, thanks
again.)

(6) As I was about to add another comment to MR#2, Phil did something
(I'm unsure what -- maybe the action was the opening of MR#3?) that
killed MR#2 altogether. All the comments, even the MR#2 summary, were
lost. The first symptom that made me notice this was that when I clicked
the "Comment" button under MR#2, GitLab complained that there must have
been a network error, because saving the comment failed. In reality MR#2
had been killed by then -- I realized that when I attempted to reload
MR#2 in full. See
<https://gitlab.com/philmd/edk2-platforms/merge_requests/3>.


Note that the above summary may be incomplete. Due to a combination of
(5) and (6), that is, due to no emails of my own actions and due to MR#2
vanishing without a trace, I can't re-read our discussion in MR#2.

Quite unintentionally, this ended up being *splendid* evidence why I
absolutely insist on a complete email audit trail.


If I missed various aspects of GitLab (which is quite likely), please do
educate me. I don't mean to say that everyone else should stop
investigating GitLab -- perhaps more seasoned GitLab users can fill the
potholes I fell into.


After having looked at GitHub, Phabricator, and GitLab, my personal
preference remains the mailing list. A *distant* second is GitHub.
(GitHub is "almost there", but its emails significantly lack context.)
And Phabricator and GitLab just don't cut it for me; Phabricator doesn't
map to multi-patch series to begin with, and GitLab is too resource
hungry, and it did a terrible job (for me anyway) preserving history.

Can someone setup Gerrit for a test drive?...

(Honestly, at this point, I'm slightly scared/prejudiced of what I might
find there.)

Thanks,
Laszlo

Re: GitLab results from my POV [was: Research Request]

[Rebecca Cran]

On Wednesday, 12 December 2018 06:20:24 MST Laszlo Ersek wrote:

> After having looked at GitHub, Phabricator, and GitLab, my personal
> preference remains the mailing list. A *distant* second is GitHub.
> (GitHub is "almost there", but its emails significantly lack context.)
> And Phabricator and GitLab just don't cut it for me; Phabricator doesn't
> map to multi-patch series to begin with, and GitLab is too resource
> hungry, and it did a terrible job (for me anyway) preserving history.
> 
> Can someone setup Gerrit for a test drive?...

Hopefully we'll be able to pick this up again in the new year.

-- 
Rebecca

about 'sr.ht' [was: Research Request]

[Laszlo Ersek]

On 11/14/18 19:34, stephano wrote:
> 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.

I'm not making a real proposal for "sr.ht" at this time, just raising it
as one collaboration software ("forge") that seems to get its goals
exactly right (in my opinion anyway):

  https://lwn.net/SubscriberLink/775963/e9849144cef5c99d/
  https://drewdevault.com/2018/11/15/sr.ht-general-availability.html
  https://lwn.net/Articles/776296/

It is admittedly alpha at this point, hence likely unsuitable for
production use. If it were a mature project, it would be extremely
attractive to me. I hope I can keep an eye on it over time.

Thanks,
Laszlo