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 <[email protected]> Sent: Tuesday, December 4, 2018 10:27 AM To: Jeremiah Cox <[email protected]>; Brian J. Johnson <[email protected]>; stephano <[email protected]> Cc: [email protected] 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
