Coding Standard: Automation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/clang-format-sample]

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

-Amar

Coding Standard: Automation

BJ: https://bluejeans.com/205933580

We will talk and come to agreement on https://bugzilla.redhat.com/show_bug.cgi?id=1564149

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/ClangFormatStyleOptions.html

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)

  BinPackParameters=true
  AlignEscapedNewLinesLeft=false
 AlignConsecutiveDeclarations=true
  AlignConsecutiveAssignments=true
 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/glusterfs/commits/git-based-history-from-historic, as a separate branch in gluster/glusterfs would help. Again, today people has to switch repositories for this.
When
Mon Apr 23, 2018 6pm – 6:50pm India Standard Time
Who
atumball@xxxxxxxxxx - organizer
jeff@xxxxxxxxxx
nbabu@xxxxxxxxxx
srangana@xxxxxxxxxx
gluster-devel@xxxxxxxxxxx
jahernan@xxxxxxxxxx
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux