From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by mx.groups.io with SMTP id smtpd.web11.14912.1574286653703016521 for ; Wed, 20 Nov 2019 13:50:54 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@akeo-ie.20150623.gappssmtp.com header.s=20150623 header.b=i1NctRzh; spf=none, err=permanent DNS error (domain: akeo.ie, ip: 209.85.128.65, mailfrom: pete@akeo.ie) Received: by mail-wm1-f65.google.com with SMTP id y5so1389464wmi.5 for ; Wed, 20 Nov 2019 13:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akeo-ie.20150623.gappssmtp.com; s=20150623; h=from:subject:references:to:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cYkEAx5YAHvWtNIXKe5jrCKskmlxcicuXgx6lkMud8o=; b=i1NctRzhobyZIr3aonStkHIF/rSoT8es0BPXP3ogZafltY2oyXS2/NeXDYxCZdge15 WFydQuHU9eo3+19RLZLyuBmRGt8+ofXRHopxcwp2uJTDHLLKgBr5TszGnj6LOXZ/nAa6 H3sx6aW8I1OrlfR89XNJlWSk6nbfVeW6FinrimAJQehzyseC1mXn5XxCuWZjKu72HSEF EszwY90B6QL1D+0FcOrGXxgnsVwZ1Sn67v2qp6nB7QmqcxIMtZjTcc3dUdh7qtEMei8L WXfUAOrGo20aXNrARXvsqaOnkF1ZfKKtYSkhlMVjIhsOkuTrmaqIETbFbUskfjUB/Bd/ Hdkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cYkEAx5YAHvWtNIXKe5jrCKskmlxcicuXgx6lkMud8o=; b=sC23xqwv2MKZY8tC7Fdyag1fyb37ANdkGPaaiDVH5pJa2iKGfgR50oPuSmGVfywc/X dznGNhljahhQaD2l9suJt0kXGSpAhHgDJEuBa+QdcUHCfxEXbm/JTBLkTqZVeCsfiWIO AWapKy47xE1wuuS5ldzxAx2cPhWnqFtFfn45fAGR1jTX2XsrBZh9JoU+WSIsanXY6v69 e5FjE02ZlQ7jx01OQ+PWkB3NTWzBrFxq6e11AAt31pOCVAbuOPaDO/tHMznsVlzRTOWz tD2HjbQMEU27sqYprjtEZBt3TGYWELam0SvwOPRzDdtq0t80JM6xQtJyjlqyzcCfT5OP 9Yfw== X-Gm-Message-State: APjAAAUFxaSO2bBpMDmqmQe3pZdorL4dDVkBLFuAnSRPrO+j9Ebs4eDT ohZy+AU2albB9A+0u9Fea9AO6Q== X-Google-Smtp-Source: APXvYqwIT16l9sOlQ8Y6VKCMB5+IwWZMs4oWtbOL33ePO3MG41RKQdqmmzPPEZNGmedmX/h6U7hkvA== X-Received: by 2002:a05:600c:2550:: with SMTP id e16mr5880617wma.69.1574286651570; Wed, 20 Nov 2019 13:50:51 -0800 (PST) Return-Path: Received: from [10.0.0.122] ([84.203.67.47]) by smtp.googlemail.com with ESMTPSA id d9sm734406wrj.10.2019.11.20.13.50.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 13:50:50 -0800 (PST) From: "Pete Batard" Subject: Re: [edk2-devel] [edk2-platforms][PATCH 1/8] Platform/RPi: Add model family detection 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> To: Leif Lindholm Cc: edk2-devel-groups-io , Ard Biesheuvel Message-ID: <31318a9e-a7fa-b012-8746-8c703efa8161@akeo.ie> Date: Wed, 20 Nov 2019 21:50:49 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Hi Leif, On 2019.11.20 10:27, Leif Lindholm wrote: > 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. That "should" *is* the exact issue. That is the very core of what I am trying to raise here: additional time that is being incurred on contributors (as well as maintainers), which, I will continue to assert, if a project was less striving for academia excellence and more for the real life preservation of everyone's limited resources, it should be acceptable to spare when my own experience with both contributing and maintaining Open Source projects (yes, most of them not as large as EDK2, but also most of them not as small as a a single person's side project) has repeatedly demonstrated that flexibility rather than intractability with regards to rules, when they happen to save everybody's time, is one of the greatest factor in attracting quality contributions. The root of the matter is that, more than often, I have found that what "should" be a <1 min effort, turns into a 15 mins or in the worst case up to a 1 hour endeavour due to side issues stepping in. And yes, that applies even to splitting the occasional minor changes for one-liner typos (and please don't be tempted to construe these as unfamiliarity with the tools being used), though I will agree that, in most cases, it *shouldn't* be that bad. But I will firmly dispute the idea that even the most straightforward typo fix effectively takes less than a minute to accomplish when you are considering the whole picture (rather than the amount of time one may effectively be spending invoking git commands). Or are you under the impression that someone who is advocating for patch piggybacking is not concerned enough with the quality of what they submit, to actually want to validate that what they are splitting is up to good standards? Even for a one liner, ensuring that a split commit does comply to the expected standards of a project like EDK2 is more than a one minute affair. And everybody who has enough experience is familiar with a "Surely this simple one liner shouldn't break anything" that turned into a more dramatic affair than wanted. And yes, I am also considering the case where one would be doing the split from the get go rather than the one where one submitted a patchset and then a maintainer asked them to further split part of it. Therefore, if you are thinking the earlier statement you pointed to above was condescending, then I'd like to present another contender for that prize. This <1 min effort is not the reality I have been observing, or the one I am expecting anyone else to be observing, which is what is actually prompting me to want to go over these matters. Instead, I will assert that spending less than a minute splitting minor changes into a patch series is the exception rather than the rule for any contributor who does take the quality of what they submit seriously. And that is the very core of the issue, because it then becomes a matter of having to deallocate time from other endeavours, which is what I would like to see at least acknowledged instead of being dismissed as a "non issue", because, IMO, this is a matter that I think Open Source project maintainers also need to keep on their radar. >> 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 believe Ard gave a conditional example of what he thinks may happen down the line. I tried to counter with the idea that, if you try to look at the big picture, maybe the time possibly being spent that far down the line is going to be more than compensated by the time having already been saved by others. > 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. I wouldn't say completely unrelated. Though I am of course not aware of the full specifics of it, which might justify some of the delayed action that is being taken. Instead, I was trying to use it as an example of a project seemingly deciding that it should be acceptable for contributors to collectively waste what I will assert is an exceedingly large amount of time, rather than just bite the bullet and state "We're gonna pause everything and take how many number of days we need to fix that now, so that our contributors stop having to waste hours on a matter that no other major Open Source project has to make them contend with". Considering that you are happy to cite the Linux kernel as an example, let me posit the following: Do you believe that Linus would have just acknowledged that the CRLF issue as something that it is acceptable to fix years down the line and that contributors should just have to learn to accept for however long it may remain unaddressed? And that is precisely my point: How far does a project see it as acceptable to push time wastage onto contributors, be it for having to contend with CRLF issues or spending an extra 5, 10, 15 minutes here and there (sometimes more) to split couple-liners into separate patches. This, IMO, makes the CRLF matter related to this whole discussion. As a matter of fact, it is in part not seeing the matter of CRLF having been addressed a long time ago that lead me to worry enough about the direction this project wants to take to want to post about patch piggybacking for typos and style. Had EDK2 sorted CRLF, I probably would have kept this reflection to myself... > And am working towards getting rid of. That's good to hear. It genuinely can't happen fast enough as I've literally just wasted about another hour on this today... >> 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. I'm just trying to share my experience, stemmed from participating in (as well as maintaining) multiple Open Source projects, some of which worked well and others which I would qualify as more dysfunctional, where I have found that intractability in changeset rules, and the inability of maintainers to acknowledge collective "time wastage" (by insisting that rules are not there to be flexible or even debated) eventually became a deterrent to attracting contributions and, in some case, resulted in the project being left struggling. And please understand that I'm not pushing for maintainership to just accept whatever (for instance, I'm not going to state that a patch that contains 4 lines of effective code change and 4 of fixing typos/style, even super obvious one, should not be split). Just that there should be some form of balance with regards to how flexible patchset rules should be when one can expect that the collective amount of time wasted by both maintainership and contributorship can be reduced in the long run (which, in the absolute, may indeed very well incur additional time being spent by maintainership, but which, and this is my point, maintainership should understand is part of the collective effort to ensure that one of the prime resource they need to concern themselves with, i.e. the time that needs to be devoted to achieve a desired standard of code quality, is minimized for everyone rather than just a single party). > 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. Yes. And I am trying to make a point for the collective, which includes not just you, but everyone involved in the project. > Suffice to say, this aspect of TianoCore is no more negotiable than > the same aspect of linux, u-boot or QEMU. Yes, that is entirely the choice of the maintainership of a project. 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. Still I don't expect the project, or more exactly, individual attitudes with regards to what one sees as beneficial to the project, to change overnight, especially for a behemoth like EDK2. But I want to leave that point in the open so that people like you can at least reflect on it when they are confronted with various aspects of the project's life, which *may* eventually lead them to rethink, as it happened to me, whether *some* amount of flexibility can actually be more beneficial to a project than over reliance on intractable rules. > I will be sorry to see you stop contributing to TianoCore if that is > the effect, I'm not planning to. As a matter of fact, some years ago, I might have made the same arguments you are making to dismiss my very own point, as it's only from participating in multiple projects that I have come to realize the importance of minimizing time wastage when it comes to keeping a project attractive. So I don't consider this discussion, regardless of its outcome, as something that would ever lead me to quit wanting to contribute to EDK2 altogether. And I also certainly hope that this discussion does not come across as as me berating maintainership of the project, which, when compared to other projects, I think is actually doing a very fine job overall (even if I may come to disagree with some the more minute aspects of what is for best when it comes to maintaining a project). It will however limit my willingness to fix low-hanging fruits, as I can't recall instances where ones I've tried to fix in the past were the <1 min effort you talk about. Even the patch you sent where you effectively did the splitting ended up being a 10-15 mins job to integrate and resulted in me having to manually edit stuff. And that is not even taking into account the time incurred by having to rework the second patch in the series or work needed to get the repo to a state where said patch should have been applicable. > but I am not willing to continue to rehash the very > fundamentals of open source development. Open Source is what we make it. I believe it is still new enough to still be trying to figure out the "rules" that work best. I certainly wouldn't say we have figured everything yet to be sure that some of the rules we currently apply don't warrant further tweaking... Regards, /Pete PS: If folks start to think that discussion is becoming too distracting for the list, then I have no problem taking it off-list, tough I would assert that I've pretty much covered everything I wanted to expose with regards to my position at this stage.