Re: [edk2-announce] Research Request

[Laszlo Ersek <lersek@redhat.com>]

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