It's happening right now, and a few times a year at minimum from my memory. 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.
On Fri, Sep 4, 2020 at 8:48 PM Warner Losh <i...@bsdimp.com> wrote: > > > > On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling <kevin.bowl...@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 <i...@bsdimp.com> wrote: >> > >> > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon <lini...@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-h...@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/svn-src-head >> > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
