From owner-svn-src-all@freebsd.org Sat Sep 5 06:14:20 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DFEEE3E1AC6 for ; Sat, 5 Sep 2020 06:14:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bk44r1dMGz40yJ for ; Sat, 5 Sep 2020 06:14:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id t20so6441059qtr.8 for ; Fri, 04 Sep 2020 23:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GuTQkE3+vul2f0wyoFRTBQNCdP/zJBWrUq+H5x4nTs8=; b=P4xsVZn9gTSyZYuJ//5BsUi/JhSbdtmBGig/WPeJJOlVQvwwGFOq62LqPQ3j4oN6/f zN7xgEYoFjGzq9UZcNwG/l+0AbZbD76bgLdx/a0qLmEWIFP9zpMl42SLSx0IKfBuxLs9 B9YcnebqHLRkcJcNrxi3scNQRZ6cV72Kl/qG6ZLJUcHYg/4ms0m7WGRH/zHKxHfaBtB+ +Q2KOkJY8mf0bSO8W94RGP9xuRsdno1SJwTDuQev0gNnbV1RG91PCYm98ovunR6OfSNX Lg5hP2+jCGbS/L8wKVLjyQEsYLhx0A2d19j6pwvVZlsDBa9wryb/VjA5CqO1Dot7K9WH cB3g== 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=GuTQkE3+vul2f0wyoFRTBQNCdP/zJBWrUq+H5x4nTs8=; b=rk5f7gwQ4tIuLWTn7WPVt1ep/WfnfZi8qJSNOU4U+FnA1La/0YRAbKAy9YD47Tg6dr cdUZFU9EGKA7Lp8pWFxUZaBBULxnaXDyRwthMa/TevFdEQn4Z7Com+ds+KKG+uJfovat pVG+cLcHaz0wEV2TVVJwxwXFg66QkU/idshyEAAOF+9B0+pPeu55pQnSIv9ZEC1zIZ8r om4GHgeVN/QzTXcLpk6BCHXGNqiPzLpgs92Z59F944KWICj7RI15bGwsOEVcybGV73P3 CCXuKqQ+M4aPo/8b4L6BnJNt1lASzqXrbwVe2JDPtGvljPVGIdch9chalUZPF33R5LlB DW3w== X-Gm-Message-State: AOAM530e17ypX83REYroDMWD0gAeZ8aLP0663y68qNV0mCmEJmMS7fKj RL01w0HRpAy84yGwJVQnktDKPOFju+rWVJcnmRaJ/A== X-Google-Smtp-Source: ABdhPJzQFs09a7x2/WC2nyRVfVSq1JtGe+k/W8jcfL210wZtlpINSCNDHSEvQVkoPuv2Z9nw4hcXpA03eJG/cPJQrKY= X-Received: by 2002:ac8:3261:: with SMTP id y30mr12226940qta.242.1599286458468; Fri, 04 Sep 2020 23:14:18 -0700 (PDT) MIME-Version: 1.0 References: <202009012119.081LJERb018106@repo.freebsd.org> <95844C00-D10A-456D-AD29-DF572043074F@fh-muenster.de> <20200902020507.GA38274@FreeBSD.org> <20200902180626.GA88595@FreeBSD.org> <6124a908-25a5-e023-16da-7963ba229b7f@FreeBSD.org> <08636D5E-AA07-4AE7-B5AC-656B08CF564B@fh-muenster.de> <20200903024226.GA54078@FreeBSD.org> <60ea593f-8258-e30d-b897-f162168b44d3@cs.duke.edu> <20200905010510.GA26297@lonesome.com> In-Reply-To: From: Warner Losh Date: Sat, 5 Sep 2020 00:14:07 -0600 Message-ID: Subject: Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgraph... To: Kevin Bowling Cc: Mark Linimon , Andrew Gallatin , Alexey Dokuchaev , Michael Tuexen , Pedro Giffuni , Mateusz Guzik , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4Bk44r1dMGz40yJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=P4xsVZn9; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.76 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.07)[-1.068]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.009]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.68)[-0.683]; RCPT_COUNT_SEVEN(0.00)[10]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::831:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[svn-src-all]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 05 Sep 2020 07:43:50 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 06:14:20 -0000 On Sat, Sep 5, 2020 at 12:00 AM Kevin Bowling wrote: > On Fri, Sep 4, 2020 at 10:30 PM Warner Losh wrote: > > > > > > > > On Fri, Sep 4, 2020, 11:24 PM Kevin Bowling > wrote: > >> > >> It's happening right now, and a few times a year at minimum from my > >> memory. > > > > > > Can I get a pointer? > > From recent lossy memory, intel networking drivers (multiply), and the > TCP stacks which are not very conforming. If click differential in > phab and insert the query "style" you can see a lot of patches to fix > things incrementally, as well as people commenting about it in review > (usually respectfully as part of other review), or asking for people > to break style changes out of behavior changes. > None of that is passive aggressive maintainers blocking things over style issues. Asking people to fix style issues is a normal patch review. I see it in the half a dozen other projects I subscribe to in enough detail to see. All the times I've seen it appear to be normal and healthy. I get asked to do it myself at times. We fixed the social dysfunction years ago in the project that had lead to the near weekly style(9) passive aggressive outbursts. I just don't see the passive aggressive side of this at all these days. To be clear: I'm not opposed to creating a style(9) tool to format code. In fact, we have one. I'm not opposed to people using it on their own code. I just don't think the relatively large amount of churn it would take would warrant a full-sale run on the tree. Nor do I think it adds enough value to be part of a pre-commit review process, especially given the strong culture of 'the file's style is more important.' And the issues in the TCP stacks I think proves the point. The style isn't super strict about style(9) yet conforms in spirit and is still easy to read for people that have read the rest of the kernel. Bulk reformatting that would be an even bigger mistake because it's still being actively developed and throwing a wrench into those efforts would negate a lot of the good will that FreeBSD has at Netflix. And that's not to mention all the other down streams that would have even more trouble rebasing their changes forward in our tree. So against those very tangible costs, the benefit is what exactly? I'm just not seeing any real ROI to enforcing that when we can't even go a week w/o at least one build breakage it seems and our performance is all over the map due to a very real lack of on-going horizontal regression testing. I think there's other, bigger fish to try than this one, that's all. Warner > > Warner > > > >> Any time someone proposes a formatter they are thrown shade, > >> so the lack of progress there isn't surprising since the current > >> culture would require a flame proof suit to make progress. It's kind > >> of tautological that the status quo doesn't bother long time > >> contributors due to selection bias, and doesn't mean for instance the > >> lack of modern tooling is not off putting to younger developers that > >> learn new tools and wonder why > >> > >> we remain in the stone age. An example > >> we are finally overcoming is the git migration. Must we drag our feet > >> every opportunity given to modernize ourselves from the other popular > >> open source OS, or can we make obvious decisions to get ahead of them? > >> I think if you ask anyone under the age of 30 you will get a pretty > >> unanimous desire for automatic formatting. > > > > > > Why strictly enforce anything is my point? It's one more thing to bounce > a commit for an issue that's about 30th on the list of problems. Why put > any energy at all into this when there is all cost and no benefit. > > Is this a common opinion? If people are this relaxed about it then I > agree with you. > > > Warner > > > > Warner > > > >> On Fri, Sep 4, 2020 at 8:48 PM Warner Losh wrote: > >> > > >> > > >> > > >> > On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling > wrote: > >> >> > >> >> I disagree that the problem is intractable. It's just a decision and > >> >> it has a one time cost with long term benefits like paying off a high > >> >> interest loan. The intractability opinion seemed justifiable for a > >> >> long time but it's been proven false by other communities, > >> >> particularly Go and Rust and there is nothing syntactically special > >> >> about these languages that enable this; it's just a decision to make > >> >> the style fit an extant formatter. An arbitrary formater may leave a > >> >> little bit of annoyance to each person's taste, but that is a tiny > >> >> drop in the bucket compared to never having to discuss and especially > >> >> correct (which may /seem/ helpful but is pretty offputting to > >> >> newcomers). A tool does it, and it takes the wind out of any passive > >> >> aggressive bike shed opportunities from either maintainer or > >> >> contributor. It sucks that downstreams have to fall in line, but > that > >> >> doesn't stop progress on any other major changes in FreeBSD. > >> > > >> > > >> > How often are there really such bikesheds these days? I've seen no > evidence of them in the hundreds of phab reviews I've seen. It is the ghost > of the past when 10 or 15 years ago it was a big deal. Why bother creating > yet another barrier to commits because we used to suck, but now have barely > a rumble of bad behavior around it... > >> > > >> > Warner > >> > > >> >> On Fri, Sep 4, 2020 at 7:57 PM Warner Losh wrote: > >> >> > > >> >> > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon > wrote: > >> >> > > >> >> > > On Fri, Sep 04, 2020 at 02:15:04PM -0400, Andrew Gallatin wrote: > >> >> > > > and I also anticipate it will cause problems with MFCs > >> >> > > > >> > > >> > > >> >> > > And existing PRs and DRs. > >> >> > > > >> >> > > >> >> > Or we could just not bother we these changes at all. It's a pipe > dream we > >> >> > will ever be style(9) compliant in all our code, or that we can > magically > >> >> > have a tool to enforce in new commits. We have better things to > worry > >> >> > about. We should continue to ignore this non problem and for new > users > >> >> > point them at the 95% correct format thing to run their submitted > patches > >> >> > if they submit something too far out of whack. > >> >> > > >> >> > The last sweep deleted a boatload of blank lines that were in > there on > >> >> > purpose. Not worth adding them back, but still annoying to no real > benefit. > >> >> > > >> >> > I just don't see the benefits at all of doing anything here. The > few > >> >> > reviews that I've seen mention it seem to be the right level of > effort. > >> >> > > >> >> > Warner > >> >> > > >> >> > > > >> >> > _______________________________________________ > >> >> > svn-src-head@freebsd.org mailing list > >> >> > https://lists.freebsd.org/mailman/listinfo/svn-src-head > >> >> > To unsubscribe, send any mail to " > svn-src-head-unsubscribe@freebsd.org" >