From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by mx.groups.io with SMTP id smtpd.web09.5305.1574245661956565372 for ; Wed, 20 Nov 2019 02:27:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=eZed9ncn; spf=pass (domain: linaro.org, ip: 209.85.167.66, mailfrom: leif.lindholm@linaro.org) Received: by mail-lf1-f66.google.com with SMTP id q28so5793622lfp.2 for ; Wed, 20 Nov 2019 02:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rhsVSlhcGFhYaiXQD/6Q80OWjc5g05ENwZ+DzAYrkOs=; b=eZed9ncns19lZHnrumz2dA/6V4dk+nno1xAvpyU9LFEWoC5rAxdbyuMN2227qfNmXw kqMZ5yibiQVPTTYqBtd4sfKcsqDRzKq+8+X/YbF1M+fDYWe1vxZHvadvLX5DXrnLY2Ka rBAo6mWcrGj7D53VKQ1dW/DuAiJThGp6OdvYCzTfnvIMK39uA/MlvrlFWVCuq6XYETJC aJCiHEuPlPT76VaAPWeevMEFNGkcNTmXO6Pvb90tvQ0NmrBFkU+tbizfoHgzwJtJ16C5 p0wXEgf17LJVjXcLBF84RknRstWyjihPrUco6HtGFmh5D83c55bATwAthb1zzIJIaX5+ CfJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rhsVSlhcGFhYaiXQD/6Q80OWjc5g05ENwZ+DzAYrkOs=; b=RMW9aRZ015wnHKRd+EQYGlyS2GPrn3DaQ4+x7wrBBvWgxdKr8lm4v84Q8QWGNN6BZu 1/CI8K6i4k6uludRsQHJI+1UeTWbsqty+K8iQ6h5DV4sthyCl2o+aJS+1CWrsDChPTe3 gQMQwpTUbjd4rWhmwpNSpqoWwBm0WsDsdcMvSIKAzvcg6fkjau/4coRH6JkbVfKoKuCO PrrKpy77B1PQLjtZGEOzZB0MpALankMJ/UcQAzv9bxZPizZmyzVOmeOH30HI9ufvMpdN 1AmktUkirwFTLJ2+LV+XJZGwSNCNI/70jgQ5myHvSiNFhE7kZBOk3DHG4nfA8VY+Nfma X1eQ== X-Gm-Message-State: APjAAAU7srXoj5cyLoOOetmesGCKrPcOAhkEpCQnl8BDEwN/GuNROqu6 aJ5rFOaZHNF3d8Pb5RWoMvoI9JHIFCfEwP3BWDXc4A== X-Google-Smtp-Source: APXvYqwx3k7pbLKeZxu5i0DaelJYZ/ssOTD6/ZVcvlIxnxoAn/wFxtTGT88xciSJ/R0KV0dwjlFPgPRhwgWUIsyEsDE= X-Received: by 2002:a19:be92:: with SMTP id o140mr2207962lff.40.1574245659912; Wed, 20 Nov 2019 02:27:39 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <6dbfd653-ab36-09f4-2f0d-8a9675ed5fae@akeo.ie> From: "Leif Lindholm" Date: Wed, 20 Nov 2019 10:27:27 +0000 Message-ID: Subject: Re: [edk2-devel] [edk2-platforms][PATCH 1/8] Platform/RPi: Add model family detection To: Pete Batard Cc: edk2-devel-groups-io , Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" On Tue, Nov 19, 2019 at 04:30:05PM +0000, Pete Batard wrote: > > Please keep in mind that when open source maintainers take ownership > > of your code, they assume the responsibility to ensure that it doesn't > > get broken by future updates elsewhere in the codebase, often way > > beyond the commercial lifetime of the product that is supported by > > that code. This is a sizable effort, and an important part of managing > > that effort is ensuring that the code is in an acceptable shape to > > begin with, and what 'acceptable' means differs between different > > maintainers. Not being able to revert a patch easily because it > > touches unrelated code may make our lives more difficult years after > > you have stopped caring about this platform entirely. > > I think you are actually exposing the root of the problem without realizing > it here. That is quite a condescending thing to say. > Elements that may make a maintainer's life more difficult years after the > contributor stopped working on it can actually be elements that makes, and > will continue to make, a whole lot of developers' lives much easier right > now. Much easier than occasionally using git add --patch or git-gui to stage individual hunks? Splitting occasional minor changes out into separate patches should be < 1min effort. > For instance, someone today or tomorrow (rather than 2 or 5 years down the > line) can very well copy from code that got rejected as an "Also" (say, the > one instance I found in the Pi source where a %s was used instead of a %a, > which is an easy thing to miss if you're not paying attention) and find out > they are wasting time on an issue that they would never have had to contend > with, had the EDK2 maintainership been flexible with regards to what might > be acceptable to piggyback on a patch that pertains to a specific file (IMO, > fixing typos or style should always be acceptable as a piggyback, and I'd > really like to hear how including such changes is effectively going to make > the maintainers' job that harder down the line). Ard gave a very specific example in the email you are replying to. I can give (and have given) you others, but since those have seen no reaction (either acknowledgment or detraction) from you, there seems to be little point in adding more. > And though this is a not directly related issue, I could also speak volumes > on how myself, and I assume many, many other developers, have wasted > countless hours (my current estimate puts that to around 4 to 5 hours in my > case) on the current CRLF enforcing situation with the EDK2 codebase. That is a completely unrelated issue, which I have certainly also wasted spectacular amounts of time on. And am working towards getting rid of. > All this to re-state that I wish there existed a balance between the well > established needs of the maintainers, and what they envision might emerge as > issues in the long run (which I assert tends to encourage them to preserve > an existing status-quo), and the possibly not so well publicized pain points > and time wastage that consumers of the codebase encounter, who, of course > (and, depending on how this discussion goes, I might come to see as perhaps > the wisest choice) generally tend to avoid venting their frustration on a > mailing list that aims at concerning itself solely with technical > discussions... This isn't a balance discussion. Either you believe that open source development happens in changesets or you do not. Either you see the value in that for debugging, or you do not. If what you care about is the ability to go back to what the tree looked like at a given point in time, then sure, a lot of this will seem very tedious to you. This does not mean that any amount of debating the topic will convince anyone who relies on the fundamentality of changesets for their workflow. > In other words, if you are willing to consider how much more painful > allowing the piggybacking of low-hanging "Also"'s onto existing patch may > make your life as a maintainer down the line, please also be willing to > envision the scenarios in which not allowing the same thing might actually > be making the life of people who work with the codebase, and I'd really like > to stress out that I'm really not talking only about myself here, harder > right now. You do realise that apart from reviewing patches, we also write and contribute code ourselves - including to several other projects? All which follow the exact same rule. Suffice to say, this aspect of TianoCore is no more negotiable than the same aspect of linux, u-boot or QEMU. I will be sorry to see you stop contributing to TianoCore if that is the effect, but I am not willing to continue to rehash the very fundamentals of open source development. / Leif