From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.21300.1574327065368529006 for ; Thu, 21 Nov 2019 01:04:25 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eU48iOyF; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574327064; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7tT3fKz012QWzzw0F8V4v065dFqKjNmFV9DU/C+XdTk=; b=eU48iOyFQ9ykBL3J9tAr8GQn/QFI8teyHz5Dw+8WVQR8XtnVf02Kh+/EC34NClLZSw0wVR cV3YHDX5rRLw6c9YBuiCiSPTH6uexlm72bz+5W4bUs2B6swLXWiCX6btlROEZRhvDev9aU 2YjmMY7Ar2jP9IJXWEhFCA3nNNvfr8A= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-80-939NQgRuNUGuoDjpbCT73A-1; Thu, 21 Nov 2019 04:04:20 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B6E18593A2; Thu, 21 Nov 2019 09:04:19 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-197.ams2.redhat.com [10.36.116.197]) by smtp.corp.redhat.com (Postfix) with ESMTP id 66E4063637; Thu, 21 Nov 2019 09:04:18 +0000 (UTC) Subject: Re: [edk2-devel] [edk2-platforms][PATCH 1/8] Platform/RPi: Add model family detection From: "Laszlo Ersek" To: devel@edk2.groups.io, pete@akeo.ie, Leif Lindholm Cc: Ard Biesheuvel References: <20191114160740.10072-1-pete@akeo.ie> <20191114160740.10072-2-pete@akeo.ie> <20191118175156.GX7323@bivouac.eciton.net> <99b30bf5-a9c6-62aa-f7e2-7db9c2bc9848@akeo.ie> <20191118180521.GY7323@bivouac.eciton.net> <3e51f090-9391-1c59-5a64-c2927011ccb1@akeo.ie> <6dbfd653-ab36-09f4-2f0d-8a9675ed5fae@akeo.ie> <31318a9e-a7fa-b012-8746-8c703efa8161@akeo.ie> Message-ID: <14a4ed1a-fcea-0c8f-15c5-5142d4e72c5c@redhat.com> Date: Thu, 21 Nov 2019 10:04:17 +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.15 X-MC-Unique: 939NQgRuNUGuoDjpbCT73A-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/21/19 09:55, Laszlo Ersek wrote: > On 11/20/19 22:50, Pete Batard wrote: >=20 >> [...] >> >> Which is why I am trying to invite them to consider one aspect that I >> believe is often overlooked: trying to treat time as the 3d most >> valuable resource a project needs to concern itself with (end-user >> experience being first and overall code/software quality second), and >> applying flexibility to what some might be a bit too eager to treat as >> non-negotiable rules as a result of that. Rules should be made to serve >> and foster those resources rather than the opposite. >=20 > Contribution rules are already made to prioritize time and effort -- > *maintainer* time and effort. >=20 > - There are fewer maintainers than contributors. >=20 > - Maintainers tend to stick around for long, contributors may or may not > (it varies). >=20 > - Maintainers generally take more responsibility for the codebase, as a > whole, than contributors do. >=20 > - In most cases, reading code is more difficult than writing code. >=20 > All of the above turn maintainership and patch review into a permanent > bottleneck at the project level. Unclogging that bottleneck is what > project rules prioritize. >=20 > Nobody doubts that strict contribution rules create bottlenecks on the > contributor side. That's the lesser wrong. "Moving fast" leads to > regressions. In a halfway mature project, which users have grown to rely > on, regressions destroy end-user experience (which you put as first > priority). BTW I don't claim that "strict rules" are the only way to keep regressions out. Many projects that "move fast" justify moving fast, and justify easing up on patch review, with having thorough CI. "Thorough CI" is also not easy though (in particular integration tests) -- keeping the test suite up-to-date, reviewing patches for the tests (incl. test infrastructure), plus operating the test environment, also require time and effort. Thanks Laszlo