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 3FA672194D3B8 for ; Fri, 8 Feb 2019 12:33:10 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A1C7E10F9F; Fri, 8 Feb 2019 20:33:09 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-123-48.rdu2.redhat.com [10.10.123.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id 09E3961146; Fri, 8 Feb 2019 20:33:07 +0000 (UTC) To: Rebecca Cran , edk2-devel@lists.01.org References: <9313a877-0c8b-2f23-1800-f6f8e8a1d6ee@redhat.com> From: Laszlo Ersek Message-ID: <7c439d2e-4d1b-6d99-515c-324e545a1235@redhat.com> Date: Fri, 8 Feb 2019 21:33:06 +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.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 08 Feb 2019 20:33:09 +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 20:33:11 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 02/08/19 18:33, Rebecca Cran wrote: > > On February 8, 2019 at 2:01:59 AM, Laszlo Ersek (lersek@redhat.com(mailto:lersek@redhat.com)) wrote: > >> 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. > > I don’t recall coming across the patch series (e.g. the 1/5 email patches) in other projects. In other projects people post a single patch and then update it following feedback on the same review. This can be either in a single, rebased commit, or new commits on a bug/feature branch - review systems deal with both. How do they contribute a feature consisting of 1500-3000 lines, in one well-structured, coherent "package"? I don't think that any single patch can carry that weight. Only a patch series can. Regarding "new commits on a bug/feature branch" -- that really doesn't look good to me, as a way to develop a focused, larger feature. Even if the initial patch looks good (in separation), it cannot really be evaluated without getting some kind of perspective, i.e. seeing where the whole thing leads in mid-distance. Sometimes we find a design bug in patch 08/12 that invalidates patch 03/12. I wouldn't want to push 03/12 until I review (and maybe even test / regression-test) the full dozen. We need this to scale to 50+ patches in a series. Such a series is not posted every day, but it does happen. That's when we need the tooling to carry us the most. [...] Obviously: I welcome all comments on this, in disagreement too! Thanks! Laszlo