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...

Sat Sep 5 06:14:20 UTC 2020

On Sat, Sep 5, 2020 at 12:00 AM Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> On Fri, Sep 4, 2020 at 10:30 PM Warner Losh <imp at bsdimp.com> wrote:
> >
> >
> >
> > On Fri, Sep 4, 2020, 11:24 PM Kevin Bowling <kevin.bowling at kev009.com>
> 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 <imp at bsdimp.com> wrote:
> >> >
> >> >
> >> >
> >> > On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling <kevin.bowling at kev009.com>
> 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 <imp at bsdimp.com> wrote:
> >> >> >
> >> >> > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon <linimon at lonesome.com>
> 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 at freebsd.org mailing list
> >> >> > https://lists.freebsd.org/mailman/listinfo/svn-src-head
> >> >> > To unsubscribe, send any mail to "
> svn-src-head-unsubscribe at freebsd.org"
>