From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by mx.groups.io with SMTP id smtpd.web12.29420.1574366559519713063 for ; Thu, 21 Nov 2019 12:02:40 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@akeo-ie.20150623.gappssmtp.com header.s=20150623 header.b=WDF4Lo+B; spf=none, err=permanent DNS error (domain: akeo.ie, ip: 209.85.221.65, mailfrom: pete@akeo.ie) Received: by mail-wr1-f65.google.com with SMTP id y11so2860705wrt.6 for ; Thu, 21 Nov 2019 12:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akeo-ie.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=619qQqy3LWkc18hBHLYsYhAwpXVTOJ06dOEZqWCQzDM=; b=WDF4Lo+BH+s0TKppENFJvn95deA6V2+SlBr2IsSvqDtnhzy0G0MrNKhO7PPpsKgqKy xpATlrMA0++V21BRxOEjBwoJM9Kk5UYFtY4rUeS8DpBhO3ZyBBdkQxiGAuiLW9wxG383 QGhm6BPBb2Z+pS8XEMtN0Ps1Byx0MjHkPooQrTfdTXOkhMRw2JR95CNhnyzHilzxDH3t ealvudDowIhdlntACLXptscfWLHjmjDCDCFvk7ZBqRXjvDG6VxTL+UPxMtxhU6Iuwf2C kyimO3JEMhCz3J88lhd3C6dGTHihUpGaywvOkiZ0NRCYqvigoJiHZOZej54EKF/VyiDn lw9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=619qQqy3LWkc18hBHLYsYhAwpXVTOJ06dOEZqWCQzDM=; b=pkOi+0TwnhGlPa2/uF6F7mH2Kc2mobHY1rMKqgSONcTo0BApKrpyp0JTSkOlSCqMZL O7oF8oByq9xDNeiO4FEe+5iIktC+IJyjplS7k3rbvlhyUKQQ/wG60KymtvC0i/UJjzAd MdaqO4N36o1y+qDNUjdoTG9r7CC/xJxDzxOIlzMvPkenEtRCEOd4Axnzgfx67avUtx5l 8VvrYTj1DMrEYPE1yR+yMcyXWz7oKhXdurkE3rxNVT9vAODQ0uvOKS6alhSS5HBhqHlg 9tkt13WvwTMEIkrjyexy84uKXaR5PqpJy6RPZTK6/cJbPspob3Kli4zjoQAeg0c/eqZ5 faiA== X-Gm-Message-State: APjAAAXxxG41yUEj+BpWWGvvDKTE+NSzN6zXco/9vQpWQkl8cvAjrgc1 8VRuj5UWKQGs7E9fc/xbZ2zoOg== X-Google-Smtp-Source: APXvYqyNRATSOQSriFWJrLSbIwAt3z8aVqLfXKogh9AItvX/bG1V9p3w9kCqAk4d4Gt3/dbPTS8whw== X-Received: by 2002:adf:f504:: with SMTP id q4mr13194174wro.160.1574366558017; Thu, 21 Nov 2019 12:02:38 -0800 (PST) Return-Path: Received: from [10.0.0.122] ([84.203.67.47]) by smtp.googlemail.com with ESMTPSA id c4sm4886374wrp.86.2019.11.21.12.02.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 12:02:36 -0800 (PST) Subject: Re: [edk2-devel] [edk2-platforms][PATCH 1/8] Platform/RPi: Add model family detection To: Laszlo Ersek , devel@edk2.groups.io, 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> <14a4ed1a-fcea-0c8f-15c5-5142d4e72c5c@redhat.com> From: "Pete Batard" Message-ID: Date: Thu, 21 Nov 2019 20:02:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <14a4ed1a-fcea-0c8f-15c5-5142d4e72c5c@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Hi Laszlo, I appreciate your input on this. However, I find it unfortunate that you seem to be equating my concern about minimizing time wastage to "moving fast", as those are two very different matters, and "moving fast" isn't what I have been trying to advocate for at all. None of the points I tried to raise are borne from what you might perhaps have perceived as a contributor's frustration about a project not moving fast enough in their eye. Especially, considering that I've literally had to deal with Open Source projects where integration of some patches became a multi-year affair (and where this extended delay had nothing to do with the usual review/rework/resubmit process) then I have to state that there is little to be frustrated about when it comes to how fast one is able to get things reviewed and integrated in the EDK2. Yet, one can move fast or slow, and still waste time. I guess if I wanted to address some of the points you raise, I could mention that lack of flexibility with regards to some rules can come as a deterrent to contributors, especially new ones if they have to spend what they perceive as an unwarranted amount of their time on elements that they'll be hard pressed to see actual tangible benefits of for the project as a whole, and how this may ultimately play into contributors not wanting to stick around (with the end result of increased work and wasted time for maintainers). But I feel like I would mostly be a re-hashing of what I have already tried to point out. Therefore, with the clarification above having been made, I am planning to leave the matter at that. Regards, /Pete On 2019.11.21 09:04, Laszlo Ersek wrote: > On 11/21/19 09:55, Laszlo Ersek wrote: >> On 11/20/19 22:50, Pete Batard wrote: >> >>> [...] >>> >>> 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. >> >> Contribution rules are already made to prioritize time and effort -- >> *maintainer* time and effort. >> >> - There are fewer maintainers than contributors. >> >> - Maintainers tend to stick around for long, contributors may or may not >> (it varies). >> >> - Maintainers generally take more responsibility for the codebase, as a >> whole, than contributors do. >> >> - In most cases, reading code is more difficult than writing code. >> >> 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. >> >> 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 >