From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BC2B8211963F4 for ; Tue, 4 Dec 2018 10:26:49 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1EED4C78E0; Tue, 4 Dec 2018 18:26:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-124-211.rdu2.redhat.com [10.10.124.211]) by smtp.corp.redhat.com (Postfix) with ESMTP id C2EAC7F1BB; Tue, 4 Dec 2018 18:26:47 +0000 (UTC) To: Jeremiah Cox , "Brian J. Johnson" , stephano Cc: "edk2-devel@lists.01.org" References: <4330857f-4e27-632f-6f82-6fc6ec636b2e@linux.intel.com> <76cb4d25-7eff-b19b-0dd5-2fcc3a1e7d82@redhat.com> <5c92dfcf-f98c-9828-5608-fd7d74fe3b3a@redhat.com> <838b16fd-9821-c64c-19f4-aafb63140b6c@redhat.com> From: Laszlo Ersek Message-ID: <0b2ce1b0-93ab-aef2-d192-23fd84024b70@redhat.com> Date: Tue, 4 Dec 2018 19:26:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 04 Dec 2018 18:26:49 +0000 (UTC) Subject: Re: [edk2-announce] Research Request X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 18:26:50 -0000 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit 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