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
You have been invited to the following event.
Title: Coding Standard: Automation
BJ: https://bluejeans.com/205933580We will talk and come to agreement
on https://bugzilla.redhat.com/show_bug.cgi?id=1564149It 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.htmlAlso 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 = trueMore 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:
* atumb...@redhat.com - organizer
* j...@pl.atyp.us
* nb...@redhat.com
* srang...@redhat.com
* gluster-devel@gluster.org
* jaher...@redhat.com
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
