[Gluster-devel] Coverity covscan for 2018-04-23-62437c99 (master branch)

[staticanalysis]

GlusterFS Coverity covscan results are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-04-23-62437c99
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Coding Standard: Automation

[Nigel Babu]

I hope I've made the changes that Jeff's recommended in the first comment
correctly[1]. 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.

[1]:
https://github.com/nigelbabu/clang-format-sample/commit/733394939034ff9baaf579e7f327bdd078f204ef

On Mon, Apr 23, 2018 at 12:58 PM,  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/
> 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*
> •
> atumb...@redhat.com - organizer
> •
> j...@pl.atyp.us
> •
> nb...@redhat.com
> •
> srang...@redhat.com
> •
> gluster-devel@gluster.org
> •
> jaher...@redhat.com
>



-- 
nigelb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Coding Standard: Automation

[atumball]

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  
onhttps://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