[edk2] [edk2-announce] Research Request
lersek at redhat.com
Tue Dec 4 10:26:46 PST 2018
On 12/03/18 18:22, Jeremiah Cox wrote:
> 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.
> 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:
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:
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
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
OK, so let me summarize my points, from:
- this thread,
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
- 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
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
- 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.
More information about the edk2-devel