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 529B22194D3B8 for ; Fri, 8 Feb 2019 01:02:03 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A74F780F8E; Fri, 8 Feb 2019 09:02:02 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-74.rdu2.redhat.com [10.10.120.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id E160F2BFA3; Fri, 8 Feb 2019 09:02:00 +0000 (UTC) To: Rebecca Cran , edk2-devel@lists.01.org References: <793375cd-f55a-fa22-97c2-d6fd04da7d8b@linux.intel.com> <8725413.RH3biPoPvx@photon.int.bluestop.org> From: Laszlo Ersek Message-ID: <9313a877-0c8b-2f23-1800-f6f8e8a1d6ee@redhat.com> Date: Fri, 8 Feb 2019 10:01:59 +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: <8725413.RH3biPoPvx@photon.int.bluestop.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 08 Feb 2019 09:02:02 +0000 (UTC) Subject: Re: [edk2-announce] Community Meeting Minutes 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: Fri, 08 Feb 2019 09:02:03 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/08/19 07:41, Rebecca Cran wrote: > On Thursday, 7 February 2019 11:30:38 MST stephano wrote: > >> My apologies if I was not clear in the minutes. We are not rejecting >> Github, but rather taking time to evaluate how we can supplement >> Github's features to emulate our current patch review requirements. We >> do not want to rush into change and risk losing data or causing >> frustration for those developers currently contributing on a regular basis. >> >> I am currently working off this list of issues that Laszlo brought up: >> >> https://lists.01.org/pipermail/edk2-devel/2018-December/033509.html >> >> To be clear, Laszlo is not the only package maintainer that has voiced >> these concerns. The longevity of pull request branches and the fact that >> email notifications lack context are top on my list. There are several >> ways to overcome these obstacles, and finding the best solution will >> ensure that if we transition to Github, that transition is successful. >> >> The ability to allow developers to work offline (or with intermittent >> connections) is an important aspect as well. We cannot practice >> exclusionary or ostracizing behaviors if we expect to grow and maintain >> a community. I cannot imagine that Github has become as popular as it is >> if it cannot facilitate ease of offline use. > > I wonder if Phabricator could be considered again, since I believe it supports > all the features mentioned: the only thing it doesn't support as a first-class > feature is mutli-patch reviews, which need to be done by linking separate > reviews together using the dependency feature. I wonder if it could either be > enhanced to support that, or people's workflow modified? I don't see the workflow modification as viable. The "patch series" concept is integral to every single open source project that I've ever worked with. The evolution of a feature or a bug fix over a series of patches is a core facet of programming and reviewing. It communicates a thinking process, and that's what programming is about. Enhancing Phabricator is of course an option, but I'm not sure how practical that is. Then we start talking time frames and it becomes sort of a competition. If GitLab added features of fixed the grave issues we had found with it, we'd have to re-evaluate GitLab too. Or else, if we had a completely leisurely time frame at our disposal, I would 100% vote -- see the introduction at . gets right *everything* right from the design principles; too bad it's only Alpha at this point. So how long do we wait? What I find practical at this moment is what Stephano has been working on (thank you for all that Stephano) -- collect & file official improvement requests with GitHub, and then see how those things are addressed. In my opinion (not having seen Gerrit anyway, which remains to be evaluated, but not by me), GitHub is the direct runner up to the mailing list, so improving GitHub would be the most practical. In particular I envision the context improvements for the GitHub email notifications as something very doable for GitHub. Thanks, Laszlo