[Gluster-devel] Coding Standard: Automation
nigelb at redhat.com
Mon Apr 23 09:19:25 UTC 2018
I hope I've made the changes that Jeff's recommended in the first comment
correctly. Xavi, I've not pulled in any of your suggestions yet, because
I figured you'd want to see the output and send suggestions.
Please send pull requests to the .clang-format file (and only that file)
for anything I've missed or anything you think needs changing. I'll do the
re-generation so we're not stuck with merge conflicts.
On Mon, Apr 23, 2018 at 12:58 PM, <atumball at redhat.com> wrote:
> Planning to postpone this meeting, and idea is to work in more
> collaborated way off-line, instead of being in a meeting. we believe it
> would give everyone (those who didn't attend) too a fair chance to submit
> their opinion.
> For now, we will continue with Nigel's clang-format repo for this to
> experiment with different options. [https://github.com/nigelbabu/
> The plan on this is to go with a sample gluster file, which would have
> complex macros, a call with STACK_WIND/UNWIND function call. A switch case,
> a for loop, a do/while loop. Also a list_for_each loop. Have locked region.
> A sample 4-5 level depth if/else checks, etc.
> With this sample file, having the .clang-format decided as either Chromium
> or Mozilla as a base (with IndentSize set to 4 space), would be a good
> start. We will also make sure to have all the agreed points in bugzilla,
> and add it to clang-format file, and also regenerate the sample file. So,
> everyone gets an idea how the target file would look like. If everyone
> agrees, by the end of the week, we will have an agreement, so we can go
> ahead and make this possible before 4.1 release branching. (So, our
> backport efforts will be reduced drastically).
> Coding Standard: Automation
> BJ: https://bluejeans.com/205933580
> We will talk and come to agreement on https://bugzilla.redhat.
> It was agreed that we will go ahead with format change automation, so,
> goal of this meeting is to pick the right options.
> Goal is to get gluster's own `.clang-format` file. Once that file is
> agreed upon, we will go ahead and create a job for fixing the patches for
> format, and also fix the codebase to get the formats.
> Pre-work if you are interested, read about : https://clang.llvm.org/docs/
> Also pick a gluster file which would pass through agreed format, so you
> can validate how it looks after formatting. Instead of waiting for this to
> happen, we can see is this good enough?
> Few things we mostly agree:
> !AllowShortIfStatementsOnASingleLine !AllowShortLoopsOnASingleLine BraceWrapping(!AfterControlStatement) BraceWrapping(AfterFunction) BraceWrapping(!BeforeElse) ColumnLimit(80) IndentWidth(4) PointerAlignment(PAS_Right) SpaceBeforeParens(SBPO_Always) TabWidth(8) UseTab(UT_Never)
> AlwaysBreakAfterReturnType = true
> More options which we can discuss:
> !IndentCaseLabelsSpaceBeforeParens = ControlStatements
> I propose two steps as preventing history:
> * The commit before the mass-format-change commit will maintained as a
> separate branch. (No cost of space, but everyone clearly knows where to go
> for history, when git blame pointing to the commit of mass changes).
> * Similarly, to get history of pre-2009 (currently 'historic' repo), I
> personally feel moving https://github.com/amarts/
> as a separate branch in gluster/glusterfs would help. Again, today people
> has to switch repositories for this.
> Mon Apr 23, 2018 6pm – 6:50pm India Standard Time
> atumball at redhat.com - organizer
> jeff at pl.atyp.us
> nbabu at redhat.com
> srangana at redhat.com
> gluster-devel at gluster.org
> jahernan at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel