[llvm-dev] [RFC] Semi-Automatic clang-format of files with low frequency

Tue Jun 30 10:27:48 PDT 2020

On Tue, Jun 30, 2020 at 10:18 AM Nicolai Hähnle via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, Jun 30, 2020 at 6:26 PM Chris Tetreault via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I’m in favor of this because, like you said, unless we do something like
> this, we’ll never get there. Frankly, I think the inactive period should be
> much shorter. I would even go so far as to say something like 1 month of
> inactivity. This codebase is under heavy development, so any code under
> active development will likely be touched in a 1 month period. 6-12 months
> will only catch the truly stable code, but any code that only gets minimal
> changes will never reach 100% coverage.
>
> Hard no on the shorter period. I have changes I'm working on for
> several months at a time. 1 year is a minimum for this in my opinion.
>
>
> > I’m sympathetic to the argument that these sorts of change make managing
> downstreams more difficult, I maintain one myself.  However, I would argue
> that finishing the formatting as fast as possible will reduce downstream
> pain because after the codebase is completely formatted, it’ll just be done
> and there will be no more formatting churn. As it stands, we constantly
> have to deal with formatting changes because there’s always new ones.
>
> First of all, we don't currently have to deal with constant formatting
> changes, at least not in the part of the code that's relevant to
> AMDGPU. Why? Because we follow the (good!) rule of avoiding gratuitous
> churn. This works _fine_.
>
> Second, these kinds of things never work out that way. You think you
> change everything once, but for one thing, tastes and fashions change.
> For another, you probably wouldn't capture everything that everybody
> wants captured. This thread talks about clang-format. Fine, but other
> people talk about changing variable naming styles, and so on.
>
> Code style just doesn't matter that much, but churn does. Don't you
> folks have more pressing matters to work on? If you're bored in your
> current job, consider applying with us :P
>
>
I don't think this is a productive comment - it attacks the person and
their contributions rather than addressing the matter at hand. Also there's
quite a lot of research out there that has things like uniform code
formatting and variable naming actually help productivity of a project as a
whole so there's that as well.

Thanks.

-eric

> Cheers,
> Nicolai
>
>
>
>
> >
> >
> >
> > Thanks,
> >
> >    Christopher Tetreault
> >
> >
> >
> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
> MyDeveloper Day via llvm-dev
> > Sent: Sunday, June 28, 2020 8:31 AM
> > To: llvm-dev <llvm-dev at lists.llvm.org>
> > Subject: [EXT] [llvm-dev] [RFC] Semi-Automatic clang-format of files
> with low frequency
> >
> >
> >
> > (Copying from Discourse)
> >
> > All
> >
> > A couple of months ago I added the following page documentation
> Clang-Formatted-Status to track the status of “How Much” clang-formatted the
> >
> > LLVM/Clang project is.
> >
> > I’m a contributor to clang-format and would like to see LLVM 100% clang
> formatted so we can use LLVM as a massive test-suite for clang-format when
> we make changes.
> >
> > In the last couple of months since we added this page the % has gone up
> by ~4% and this is likely in most part of either: a mention in LLVM-Weekly,
> the premerge checks or perhaps some recent clang-format efforts by
> individuals. This is fantastic and every directory that gets to 100%
> increase the directories that I can run against to check against.
> >
> > However, it recently twigged to me that files that don’t change very
> often are never going to be 100% clang-formatted simply by virtue of
> clang-formatting all new changes.
> >
> > So I 100% understand this kind of topic comes up from time to time and I
> understand that we don’t want to automatically clang-format the entire tree
> as this can disrupt peoples downstream forks, especially where they
> actively have code inflight.
> >
> > But I wonder if we could have a general rule that said a [NFC]
> clang-format change could be made on ANY file that had NOT been changed in
> a 6/12 months period? I believe this process could be automated at least in
> a semi-automatic way. Once complete the pre-merge checks should maintain
> the current status.
> >
> > This would drive the goal of completely clang-formatted source tree,
> without the disruption to current active areas.
> >
> > Any thoughts?
> >
> > MyDeveloperDay
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> Lerne, wie die Welt wirklich ist,
> aber vergiss niemals, wie sie sein sollte.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/f8e9ae97/attachment.html>