* Re: [edk2-announce] Research Request
2018-11-26 21:43 ` Jeremiah Cox
@ 2018-11-26 22:27 ` stephano
2018-11-27 9:33 ` Knop, Ryszard
2018-11-27 12:53 ` Laszlo Ersek
2 siblings, 0 replies; 43+ messages in thread
From: stephano @ 2018-11-26 22:27 UTC (permalink / raw)
To: Jeremiah Cox; +Cc: edk2-devel@lists.01.org, Sean Brogan
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&data=02%7C01%7Cjerecox%40microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783587312509548&sdata=sra5nI19QTGmCbkDBeR7QYFTVpndqZqCjzkmhO0nlsU%3D&reserved=0
>
> These are a summary from our community meetings.
>
> Enjoy the holiday!
>
> Cheers,
> Stephano
>
> On 11/20/2018 3:47 PM, Jeremiah Cox wrote:
>> Hi Stephano,
>> Sean and I will put something together for GitHub by next Tuesday.
>>
>> 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&data=02%7C01%7Cjerecox%4
>> 0microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C636783587312509548&sdata=SOR9cdCLwmsl37RB
>> S0fkk6a%2FIE1so1flDYG2%2BzjCBbQ%3D&reserved=0
>>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-26 21:43 ` Jeremiah Cox
2018-11-26 22:27 ` stephano
@ 2018-11-27 9:33 ` Knop, Ryszard
2018-11-27 21:16 ` Jeremiah Cox
2018-11-27 12:53 ` Laszlo Ersek
2 siblings, 1 reply; 43+ messages in thread
From: Knop, Ryszard @ 2018-11-27 9:33 UTC (permalink / raw)
To: Jeremiah Cox, stephano, edk2-devel@lists.01.org
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&data=02%7C01%7Cjerecox%40microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783587312509548&sdata=sra5nI19QTGmCbkDBeR7QYFTVpndqZqCjzkmhO0nlsU%3D&reserved=0
These are a summary from our community meetings.
Enjoy the holiday!
Cheers,
Stephano
On 11/20/2018 3:47 PM, Jeremiah Cox wrote:
> Hi Stephano,
> Sean and I will put something together for GitHub by next Tuesday.
>
> 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&data=02%7C01%7Cjerecox%4
> 0microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C636783587312509548&sdata=SOR9cdCLwmsl37RB
> S0fkk6a%2FIE1so1flDYG2%2BzjCBbQ%3D&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.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [edk2-announce] Research Request
2018-11-27 9:33 ` Knop, Ryszard
@ 2018-11-27 21:16 ` Jeremiah Cox
2018-11-27 22:23 ` Rebecca Cran
0 siblings, 1 reply; 43+ messages in thread
From: Jeremiah Cox @ 2018-11-27 21:16 UTC (permalink / raw)
To: Knop, Ryszard, stephano, edk2-devel@lists.01.org
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&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&sdata=4coAaUQSgmoxLC3SDsW1M0X0bu61hhWQJlP%2B1xyP%2FW0%3D&reserved=0 and https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphabricator.kde.org%2F&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&sdata=MJaEesRphYxAtZCSJ%2Fyz3ZwcT%2FmMBRGAYHL0GxD5KWw%3D&reserved=0 - so that's not a problem :)
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-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&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&sdata=g3nvEWQuUZzFBEeEpSq63lZLRoPwp06el3kiNmFjfQA%3D&reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-email-notifications%2F&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543&sdata=4k56B1IeZyK2f3d%2BX9D2q3FFpk0kHt4Jey1NlwYunzs%3D&reserved=0
Alternatively, the GitHub REST API appear to offer full export capability of all information & metadata:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fgit%2Fcommits%2F%23get-a-commit&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=JsmAP23PWWpvjgfH9XO3qR0OtW8unBujs3MCG7ABCfg%3D&reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fpulls%2F%23list-pull-requests&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=5TgHzyJNYI2YxRASb4z5QCtui100Ftz25tVxQObytrs%3D&reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fpulls%2Fcomments%2F%23list-comments-on-a-pull-request&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=iDB1PW%2B9G1Ywjj%2FFeLYtKmcBI3szuz9%2FX5rBtL0ZNxk%3D&reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fissues%2Fevents%2F%23list-events-for-a-repository&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=1lqC1ZUraFJqs8AJm0Ffd2pJGdK0lA2RA0ADteB2msQ%3D&reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fissues%2Fcomments%2F%23list-comments-on-an-issue&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=fzXJZ%2FQSLhhkAdkX5irJ6Kmu7ALwOBFXJ1J%2Fyp8hSFY%3D&reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Factivity%2Fevents%2F%23list-repository-events&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=SM1oYigZqo7hLhzpd9JC0ROmhy6mybhDsIUSVH7GBOU%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=qFB2gEBJvJ5AoQeCypTrtMIhqzDxm2mdpjXjknMiacE%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=C1bH8GSrkJT%2FHyfVJ3z86TbjxGw%2FaFtYVX3sd%2FKzyOk%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=8VcHl3KdEvHYJSuwjTSiCo74pzlw3VCBgbq%2FVwqeOUY%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=7LfJbdjJUFip0NHCCYLOfoM%2BCD9%2FI%2FzOFC7yJQyknzQ%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=JtgEwui0tzWoxOLH7YSqclJo4IJUgD5pmIm2u%2B%2B0j%2BY%3D&reserved=0
These are a summary from our community meetings.
Enjoy the holiday!
Cheers,
Stephano
On 11/20/2018 3:47 PM, Jeremiah Cox wrote:
> Hi Stephano,
> Sean and I will put something together for GitHub by next Tuesday.
>
> 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&data=02%7C01%7Cjerecox%4
> 0microsoft.com%7Caace5779691047a1809b08d64f4c7fb2%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C636783587312509548&sdata=SOR9cdCLwmsl37RB
> S0fkk6a%2FIE1so1flDYG2%2BzjCBbQ%3D&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&data=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552&sdata=t13IcLLPbGxmHxeQJAvs%2BrIoXbBk34KsJRUhIVPn010%3D&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.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [edk2-announce] Research Request
2018-11-27 21:16 ` Jeremiah Cox
@ 2018-11-27 22:23 ` Rebecca Cran
2018-11-28 18:19 ` Jeremiah Cox
0 siblings, 1 reply; 43+ messages in thread
From: Rebecca Cran @ 2018-11-27 22:23 UTC (permalink / raw)
To: edk2-devel, Jeremiah Cox
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-27 22:23 ` Rebecca Cran
@ 2018-11-28 18:19 ` Jeremiah Cox
2018-11-28 19:21 ` Rebecca Cran
0 siblings, 1 reply; 43+ messages in thread
From: Jeremiah Cox @ 2018-11-28 18:19 UTC (permalink / raw)
To: Rebecca Cran, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-28 18:19 ` Jeremiah Cox
@ 2018-11-28 19:21 ` Rebecca Cran
0 siblings, 0 replies; 43+ messages in thread
From: Rebecca Cran @ 2018-11-28 19:21 UTC (permalink / raw)
To: Jeremiah Cox; +Cc: edk2-devel@lists.01.org, Knop, Ryszard, stephano
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-26 21:43 ` Jeremiah Cox
2018-11-26 22:27 ` stephano
2018-11-27 9:33 ` Knop, Ryszard
@ 2018-11-27 12:53 ` Laszlo Ersek
2018-11-27 21:55 ` Brian J. Johnson
2 siblings, 1 reply; 43+ messages in thread
From: Laszlo Ersek @ 2018-11-27 12:53 UTC (permalink / raw)
To: Jeremiah Cox, stephano; +Cc: edk2-devel@lists.01.org
[-- 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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [edk2-announce] Research Request
2018-11-27 12:53 ` Laszlo Ersek
@ 2018-11-27 21:55 ` Brian J. Johnson
2018-11-28 11:07 ` Laszlo Ersek
0 siblings, 1 reply; 43+ messages in thread
From: Brian J. Johnson @ 2018-11-27 21:55 UTC (permalink / raw)
To: Laszlo Ersek, Jeremiah Cox, stephano; +Cc: edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [edk2-announce] Research Request
2018-11-27 21:55 ` Brian J. Johnson
@ 2018-11-28 11:07 ` Laszlo Ersek
2018-11-28 18:31 ` Jeremiah Cox
0 siblings, 1 reply; 43+ messages in thread
From: Laszlo Ersek @ 2018-11-28 11:07 UTC (permalink / raw)
To: Brian J. Johnson, Jeremiah Cox, stephano; +Cc: edk2-devel@lists.01.org
[-- 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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [edk2-announce] Research Request
2018-11-28 11:07 ` Laszlo Ersek
@ 2018-11-28 18:31 ` Jeremiah Cox
2018-11-28 22:01 ` Laszlo Ersek
0 siblings, 1 reply; 43+ messages in thread
From: Jeremiah Cox @ 2018-11-28 18:31 UTC (permalink / raw)
To: Laszlo Ersek, Brian J. Johnson, stephano; +Cc: edk2-devel@lists.01.org
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&data=02%7C01%7Cjerecox%40microsoft.com%7C86474d2516054fd63
>>> 42708d65521acec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367900
>>> 00471363695&sdata=19UcXzXaxWSI9Dwvj7Nb2p1TRa78H8nxgFznkLKYeOg%3D
>>> &reserved=0
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhel
>>> p.github.com%2Farticles%2Fabout-email-notifications%2F&data=02%7
>>> C01%7Cjerecox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C7
>>> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790000471363695&sda
>>> ta=ICXNdWhlzBzVfjKk5t5aBsMC6hY8onKZS1T3WqobERk%3D&reserved=0
>> No, they are insufficient.
>>
>> Following the last link above ("about-email-notifications"), one
>> finds several other links; and one of those is:
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp
>> .github.com%2Farticles%2Fabout-notifications%2F&data=02%7C01%7Cje
>> recox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86
>> f141af91ab2d7cd011db47%7C1%7C0%7C636790000471363695&sdata=C%2Fy1v
>> gLJC5cpL9fNQOqw1V28Omzazbu%2BeZC2m13wRLs%3D&reserved=0
>>
>> This article says,
>>
>> GitHub sends participating notifications when you're directly
>> involved in activities or conversations within a repository or a
>> team you're a member of. You'll receive a notification when:
>>
>> [...]
>>
>> - You open, comment on, or close an issue or pull request.
>>
>> [...]
>>
>> This is demonstrably false. I'm a member of the TianoCore
>> organization, I have commented on, and closed (rejected):
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> ub.com%2Ftianocore%2Fedk2%2Fpull%2F133&data=02%7C01%7Cjerecox%40m
>> icrosoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C636790000471363695&sdata=BT0dw8IxXGiopl3%
>> 2FHfJl7w%2BGG8VSlEb2rvIetin5T2o%3D&reserved=0
>>
>> and I *never* received an email notification about my *own* comment
>> / action. I only received the initial email, about the pull request
>> being opened (attached for reference).
>
> Try going to the "Settings" item under the menu in the top-right
> corner, and clicking on the "Notifications" tab on the left. Under
> "Email notification preferences" there should be a checkbox for
> "Include your own updates". That may do what you need.
That did the trick. I checked the box and then went on to close PR#134.
I got two separate emails shortly after (attached), one about the closure and another about the comment.
In my opinion, the default value for the setting in question is broken (it should be "on" by default). However, to me anyway, it's a big plus for GitHub that it actually supports this feature. If we are going to adopt GitHub, then we can highlight the knob in our docs.
Regarding GitHub, what remains to be seen (for me) is if & how it preserves old (unmerged) topic branches, and review comments made for them, after the pull requestor rebases or deletes those branches in his/her repo.
Can someone please send an artificial/test PR against my personal repo, at <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2&data=02%7C01%7Cjerecox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790000471363695&sdata=ipRDM9x1QQnMSv7PF%2BE7yf3oGg7sBE3mjeqHw9vmyDA%3D&reserved=0>? Just change some lines in OvmfPkg/README or something like that.
Thank you!
Laszlo
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [edk2-announce] Research Request
2018-11-28 18:31 ` Jeremiah Cox
@ 2018-11-28 22:01 ` Laszlo Ersek
2018-11-29 1:07 ` Jeremiah Cox
0 siblings, 1 reply; 43+ messages in thread
From: Laszlo Ersek @ 2018-11-28 22:01 UTC (permalink / raw)
To: Jeremiah Cox, Brian J. Johnson, stephano; +Cc: edk2-devel@lists.01.org
On 11/28/18 19:31, Jeremiah Cox wrote:
> Test PR submitted
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-28 22:01 ` Laszlo Ersek
@ 2018-11-29 1:07 ` Jeremiah Cox
2018-11-29 9:48 ` Laszlo Ersek
0 siblings, 1 reply; 43+ messages in thread
From: Jeremiah Cox @ 2018-11-29 1:07 UTC (permalink / raw)
To: Laszlo Ersek, Brian J. Johnson, stephano; +Cc: edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-29 1:07 ` Jeremiah Cox
@ 2018-11-29 9:48 ` Laszlo Ersek
2018-11-29 21:20 ` Rebecca Cran
2018-12-03 17:22 ` Jeremiah Cox
0 siblings, 2 replies; 43+ messages in thread
From: Laszlo Ersek @ 2018-11-29 9:48 UTC (permalink / raw)
To: Jeremiah Cox, Brian J. Johnson, stephano; +Cc: edk2-devel@lists.01.org
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
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-29 9:48 ` Laszlo Ersek
@ 2018-11-29 21:20 ` Rebecca Cran
2018-12-03 9:29 ` Laszlo Ersek
2018-12-03 17:22 ` Jeremiah Cox
1 sibling, 1 reply; 43+ messages in thread
From: Rebecca Cran @ 2018-11-29 21:20 UTC (permalink / raw)
To: Brian J. Johnson, Jeremiah Cox, Laszlo Ersek, stephano
Cc: edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-29 21:20 ` Rebecca Cran
@ 2018-12-03 9:29 ` Laszlo Ersek
2018-12-03 21:39 ` Rebecca Cran
0 siblings, 1 reply; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-03 9:29 UTC (permalink / raw)
To: Rebecca Cran, Brian J. Johnson, Jeremiah Cox, stephano
Cc: edk2-devel@lists.01.org
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
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-03 9:29 ` Laszlo Ersek
@ 2018-12-03 21:39 ` Rebecca Cran
2018-12-04 18:00 ` Laszlo Ersek
2018-12-05 12:55 ` Laszlo Ersek
0 siblings, 2 replies; 43+ messages in thread
From: Rebecca Cran @ 2018-12-03 21:39 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-03 21:39 ` Rebecca Cran
@ 2018-12-04 18:00 ` Laszlo Ersek
2018-12-05 12:55 ` Laszlo Ersek
1 sibling, 0 replies; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-04 18:00 UTC (permalink / raw)
To: Rebecca Cran
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-03 21:39 ` Rebecca Cran
2018-12-04 18:00 ` Laszlo Ersek
@ 2018-12-05 12:55 ` Laszlo Ersek
2018-12-05 17:26 ` Rebecca Cran
2018-12-05 17:31 ` [edk2-announce] Research Request Rebecca Cran
1 sibling, 2 replies; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-05 12:55 UTC (permalink / raw)
To: Rebecca Cran
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-05 12:55 ` Laszlo Ersek
@ 2018-12-05 17:26 ` Rebecca Cran
2018-12-06 14:05 ` Laszlo Ersek
2018-12-06 14:13 ` Laszlo Ersek
2018-12-05 17:31 ` [edk2-announce] Research Request Rebecca Cran
1 sibling, 2 replies; 43+ messages in thread
From: Rebecca Cran @ 2018-12-05 17:26 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-05 17:26 ` Rebecca Cran
@ 2018-12-06 14:05 ` Laszlo Ersek
2018-12-06 14:07 ` Laszlo Ersek
2018-12-06 14:13 ` Laszlo Ersek
1 sibling, 1 reply; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-06 14:05 UTC (permalink / raw)
To: Rebecca Cran
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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.
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-06 14:05 ` Laszlo Ersek
@ 2018-12-06 14:07 ` Laszlo Ersek
0 siblings, 0 replies; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-06 14:07 UTC (permalink / raw)
To: Rebecca Cran
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-05 17:26 ` Rebecca Cran
2018-12-06 14:05 ` Laszlo Ersek
@ 2018-12-06 14:13 ` Laszlo Ersek
2018-12-06 15:25 ` Rebecca Cran
2018-12-07 6:10 ` Rebecca Cran
1 sibling, 2 replies; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-06 14:13 UTC (permalink / raw)
To: Rebecca Cran
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-06 14:13 ` Laszlo Ersek
@ 2018-12-06 15:25 ` Rebecca Cran
2018-12-07 6:10 ` Rebecca Cran
1 sibling, 0 replies; 43+ messages in thread
From: Rebecca Cran @ 2018-12-06 15:25 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Brian J. Johnson, edk2-devel@lists.01.org, Jeremiah Cox, stephano
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-06 14:13 ` Laszlo Ersek
2018-12-06 15:25 ` Rebecca Cran
@ 2018-12-07 6:10 ` Rebecca Cran
2018-12-07 12:00 ` my Phabricator findings [was: Research Request] Laszlo Ersek
1 sibling, 1 reply; 43+ messages in thread
From: Rebecca Cran @ 2018-12-07 6:10 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* my Phabricator findings [was: Research Request]
2018-12-07 6:10 ` Rebecca Cran
@ 2018-12-07 12:00 ` Laszlo Ersek
2018-12-07 13:11 ` Rebecca Cran
0 siblings, 1 reply; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-07 12:00 UTC (permalink / raw)
To: Rebecca Cran
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: my Phabricator findings [was: Research Request]
2018-12-07 12:00 ` my Phabricator findings [was: Research Request] Laszlo Ersek
@ 2018-12-07 13:11 ` Rebecca Cran
0 siblings, 0 replies; 43+ messages in thread
From: Rebecca Cran @ 2018-12-07 13:11 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Brian J. Johnson, edk2-devel@lists.01.org, Jeremiah Cox, stephano
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-05 12:55 ` Laszlo Ersek
2018-12-05 17:26 ` Rebecca Cran
@ 2018-12-05 17:31 ` Rebecca Cran
2018-12-06 13:51 ` Laszlo Ersek
1 sibling, 1 reply; 43+ messages in thread
From: Rebecca Cran @ 2018-12-05 17:31 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-05 17:31 ` [edk2-announce] Research Request Rebecca Cran
@ 2018-12-06 13:51 ` Laszlo Ersek
0 siblings, 0 replies; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-06 13:51 UTC (permalink / raw)
To: Rebecca Cran
Cc: Brian J. Johnson, Jeremiah Cox, stephano, edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-11-29 9:48 ` Laszlo Ersek
2018-11-29 21:20 ` Rebecca Cran
@ 2018-12-03 17:22 ` Jeremiah Cox
2018-12-04 18:26 ` Laszlo Ersek
1 sibling, 1 reply; 43+ messages in thread
From: Jeremiah Cox @ 2018-12-03 17:22 UTC (permalink / raw)
To: Laszlo Ersek, Brian J. Johnson, stephano; +Cc: edk2-devel@lists.01.org
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&data=02%7C01%7Cjerecox%40microsoft.com%7Cab0bcfaae8d14af6b1ba08d655dfcc78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790817039792972&sdata=ibzR7PEq%2FuT%2B4Q7ZTtDYow6sYKg%2B4Awj3cpFLD9vWhw%3D&reserved=0
Thanks!
> I cannot rebase away my history from PRs...
> Hopefully you have a nice email trail too.
The emails are coming in nice, but I'm not universally pleased with the
contents. I listed some issues regarding that in
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F1&data=02%7C01%7Cjerecox%40microsoft.com%7Cab0bcfaae8d14af6b1ba08d655dfcc78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636790817039792972&sdata=TcCYyatJSFplDFHNeTp34BpG4d3%2FSA28NIMPCpyQCwQ%3D&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
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [edk2-announce] Research Request
2018-12-03 17:22 ` Jeremiah Cox
@ 2018-12-04 18:26 ` Laszlo Ersek
2018-12-05 19:09 ` Jeremiah Cox
0 siblings, 1 reply; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-04 18:26 UTC (permalink / raw)
To: Jeremiah Cox, Brian J. Johnson, stephano; +Cc: edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [edk2-announce] Research Request
2018-12-04 18:26 ` Laszlo Ersek
@ 2018-12-05 19:09 ` Jeremiah Cox
2018-12-06 13:33 ` Laszlo Ersek
0 siblings, 1 reply; 43+ messages in thread
From: Jeremiah Cox @ 2018-12-05 19:09 UTC (permalink / raw)
To: Laszlo Ersek, Brian J. Johnson, stephano; +Cc: edk2-devel@lists.01.org
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&data=02%7C01%7Cjerecox
> %40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=OoS6nyB83BGn%2
> Bg%2BNnSA4AAsNqb3e6xjpHmR7LUvU98c%3D&reserved=0
> may suffice.
I didn't miss it when you first recommended this utility, in:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F2%23issuecomment-443066812&data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=edt3z5c7%2BDNTr%2BtkvHpUkEqCppG44B13WrvUkgPI0kY%3D&reserved=0
I didn't respond explicitly because, when you made that suggestion, I had already stated on the edk2-devel list that external tools that aren't a core part of the service wouldn't cut it, for me anyway:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmid.mail-archive.com%2F76cb4d25-7eff-b19b-0dd5-2fcc3a1e7d82%40redhat.com&data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=L4eofdxURPR1HOy60ZcJW9KgE1ByPxIi09Y9slRbZ5w%3D&reserved=0
On 11/27/18 13:53, Laszlo Ersek wrote:
> GitHub has extremely good availability. I doubt that any hack we could
> come up with (and that we'd have to run ourselves, elsewhere), could
> muster the same service level. This means that sooner or later our
> mirroring hack would go down, while GitHub would stay up, and then
> we'd start losing updates to our "mirror".
>
> The offline & full coverage audit trail has to be generated by a core
> part of the service.
I don't know who "josegonzalez" is, whom he works for, what his interests are, what kind of support we can get from him (for his software), where and how we should run his software, what SLA we could get from the organization that actually runs "python-github-backup" for us, and so on.
To repeat, it suffices if we get *at least one* of
(a) comprehensive email notifications,
(b) comprehensive backup/archival functionality that is core to the
service itself.
At this point, GitHub seems to provide zero of these.
(I'll also repeat that I agree that GitHub provides a *lot* of important and useful functionality in other areas. To me those areas are not
interchangeable.)
OK, so let me summarize my points, from:
- this thread,
- https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F1&data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=xFMUbMuuj6FKA2zPMrKZ0MlSHeDIhYc0LDYpMJj92wo%3D&reserved=0
- https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flersek%2Fedk2%2Fpull%2F2&data=02%7C01%7Cjerecox%40microsoft.com%7C39e7247ecd1946a67e9c08d65a160e80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795448114734464&sdata=STndRd8YrVmWDTehLH2R7RlduAXmC7x6v%2FvgCxUR0%2BU%3D&reserved=0
On the plus side:
- It is possible to enable email notifications about one's own actions.
- It is 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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [edk2-announce] Research Request
2018-12-05 19:09 ` Jeremiah Cox
@ 2018-12-06 13:33 ` Laszlo Ersek
0 siblings, 0 replies; 43+ messages in thread
From: Laszlo Ersek @ 2018-12-06 13:33 UTC (permalink / raw)
To: Jeremiah Cox, Brian J. Johnson, stephano; +Cc: edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread