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 123B021197040 for ; Thu, 6 Dec 2018 05:33:47 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4996F65871; Thu, 6 Dec 2018 13:33:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-122-0.rdu2.redhat.com [10.10.122.0]) by smtp.corp.redhat.com (Postfix) with ESMTP id E43861001F5B; Thu, 6 Dec 2018 13:33:45 +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> <0b2ce1b0-93ab-aef2-d192-23fd84024b70@redhat.com> From: Laszlo Ersek Message-ID: Date: Thu, 6 Dec 2018 14:33:44 +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.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 06 Dec 2018 13:33:47 +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: Thu, 06 Dec 2018 13:33:48 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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