[Gluster-devel] Maintainer's meeting minutes: 17th Sept, 2018

[Amar Tumballi]

BJ Link

   - Bridge: https://bluejeans.com/217609845
   - Watch: https://bluejeans.com/s/MI4xY

Attendance

   - misc, ndevos(added few points to 'Version 5 Status),
   - Nigel, Amar, Nithya, Raghavendra Bhat, Shyam, Kaushal, Pranith, Sunny

Agenda

   -

   AI from previous week:
   - clang-format: Finally complete
  - Need to rebase patches
 - One best way is to submit it with basic changes, and
 clang-formatter job suggests the right patch to apply, and
use that to get
 the final patch.
 - Talk to Nigel/Infra team if you are blocked on rebasing the
 existing patch. He wants to understand what are the problems,
and hs, and
 how he can help.
 - [Shyam]:
  - Any feedbacks? - Use email list
  - Use bz#564149 
   -

   GCS Status:
   - Deploy scripts mostly working fine: https://github.com/kshlm/gd2-k8s
 - Few more patches required in GD2.
  - Where to send the PR ?
 - Plan is to send it to GCS, as the plan is to get more issues and
 discussions, along with documentation on that repo.
  - k8s is initial focus, openshift origin would also be added in
  future.
  -
   -

   Version 5 Status
   - Goal: Stability release
  - GD2 tagging is not done!
 - Pending on GCS dependant patches to get merged!
  - GlusterFS Branching done!
 - RC0 Tagging today (post cleanup patches are merged)
 - Need to get some cadence on testing release branches [Shyam]
- Infra bug for release dash (regression and mux to start with)
- Glusto with FUSE
- Gbench
- More ideas welcome!
 - PR to add release-5 to Jenking jobs (centosci#19
  )
  - preparations for CentOS Storage SIG
 - seeding of dependencies (cbs
 )
 - centos-release-gluster5 package with YUM .repo file (cbs
 )
 - repository sync for testing has been requested (req#15282
 )
  - Release and options notes/documentations to start [Shyam]
   -

   Triaging:
   - ~1050 Bugs
  

   (111 on 3.12, ~50 on 4.1, and 850+ on mainline)
 - ~400 MODIFIED on master (may be it gets closed on v5.0 release)
 - Everyone having a look on components and resolving would help.
 - On a glance, at least 50+ RFEs still open in Bugzilla from old
 time.
 - Use component-wise health status, and present it back to RHT
 programs.
 - AI: Nigel to volunteer to see how the status check helps. Shyam
 to help Nigel as a buddy in this effort.
- Look at tools to see most of these issues. Understand the
volume, see what is the effort needed.
 - 261 Open Github Issues
  
   -

   New Peer/Maintainers proposals:
   - Sunny to Snapshot
  - Shubendu Tripati for gluster-prometheus
  -
   -

   Round Table
   - [Nigel] Can we have a section in this meeting every month to propose
  new maintainers/peers? We seem to be quite hesitant to add new
folks (Shout
  out to Kruthika for adding Xavi).
 - Raghavenra Bhat sent one more patch for adding Sunny (to
 Snapshot).
  - [Shyam] Discuss “Lock down period merge process” mail thread
  

 - Should we block at a component level or at a project level
- Components are not tightly decoupled, hence allowing merges
in other parts can make getting to stability harder [Nigel, Shyam]
- Also, requesting at component level goes towards “good faith”
approach than tooling and process approach, so not a
direction we want to
go with as a project.




On Mon, Sep 17, 2018 at 8:49 AM, Amar Tumballi  wrote:

> BJ Link
>
>- Bridge: https://bluejeans.com/217609845
>- Watch:
>
> Attendance
>
>-
>
> Agenda
>
>-
>
>AI from 

Re: [Gluster-devel] Clang-Formatter for GlusterFS.

[Kotresh Hiremath Ravishankar]

On Tue, Sep 18, 2018 at 2:44 PM, Amar Tumballi  wrote:

>
>
> On Tue, Sep 18, 2018 at 2:33 PM, Kotresh Hiremath Ravishankar <
> khire...@redhat.com> wrote:
>
>> I have a different problem. clang is complaining on the 4.1 back port of
>> a patch which is merged in master before
>> clang-format is brought in. Is there a way I can get smoke +1 for 4.1 as
>> it won't be neat to have clang changes
>> in 4.1 and not in master for same patch. It might further affect the
>> clean back ports.
>>
>>
> This is a bug.. please file an 'project-infrastructure' bug to disable
> clang-format job in release branches (other than release-5 branch).
>
ok, done https://bugzilla.redhat.com/show_bug.cgi?id=1630259

>
> -Amar
>
>
>> - Kotresh HR
>>
>> On Tue, Sep 18, 2018 at 2:13 PM, Ravishankar N 
>> wrote:
>>
>>>
>>>
>>> On 09/18/2018 02:02 PM, Hari Gowtham wrote:
>>>
 I see that the procedure mentioned in the coding standard document is
 buggy.

 git show --pretty="format:" --name-only | grep -v "contrib/" | egrep
 "*\.[ch]$" | xargs clang-format -i

 The above command edited the whole file. which is not supposed to
 happen.

>>> It works fine on fedora 28 (clang version 6.0.1). I had the same problem
>>> you faced on fedora 26 though, presumably because of the older clang
>>> version.
>>> -Ravi
>>>
>>>
>>>
 +1 for the readability of the code having been affected.
 On Mon, Sep 17, 2018 at 10:45 AM Amar Tumballi 
 wrote:

>
>
> On Mon, Sep 17, 2018 at 10:00 AM, Ravishankar N <
> ravishan...@redhat.com> wrote:
>
>>
>> On 09/13/2018 03:34 PM, Niels de Vos wrote:
>>
>>> On Thu, Sep 13, 2018 at 02:25:22PM +0530, Ravishankar N wrote:
>>> ...
>>>
 What rules does clang impose on function/argument wrapping and
 alignment? I
 somehow found the new code wrapping to be random and highly
 unreadable. An
 example of 'before and after' the clang format patches went in:
 https://paste.fedoraproject.org/paste/dC~aRCzYgliqucGYIzxPrQ
 Wondering if
 this is just me or is it some problem of spurious clang fixes.

>>> I agree that this example looks pretty ugly. Looking at random
>>> changes
>>> to the code where I am most active does not show this awkward
>>> formatting.
>>>
>>
>> So one of my recent patches is failing smoke and clang-format is
>> insisting [https://build.gluster.org/job/clang-format/22/console] on
>> wrapping function arguments in an unsightly manner. Should I resend my
>> patch with this new style of wrapping ?
>>
>> I would say yes! We will get better, by changing options of
> clang-format once we get better options there. But for now, just following
> the option suggested by clang-format job is good IMO.
>
> -Amar
>
> Regards,
>> Ravi
>>
>>
>>
>> However, I was expecting to see enforcing of the
>>> single-line-if-statements like this (and while/for/.. loops):
>>>
>>>   if (need_to_do_it) {
>>>do_it();
>>>   }
>>>
>>> instead of
>>>
>>>   if (need_to_do_it)
>>>do_it();
>>>
>>> At least the conversion did not take care of this. But, maybe I'm
>>> wrong
>>> as I can not find the discussion in https://bugzilla.redhat.com/15
>>> 64149
>>> about this. Does someone remember what was decided in the end?
>>>
>>> Thanks,
>>> Niels
>>>
>>
>>
>
> --
> Amar Tumballi (amarts)
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>



>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Thanks and Regards,
>> Kotresh H R
>>
>
>
>
> --
> Amar Tumballi (amarts)
>



-- 
Thanks and Regards,
Kotresh H R
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Clang-Formatter for GlusterFS.

[Amar Tumballi]

On Tue, Sep 18, 2018 at 2:33 PM, Kotresh Hiremath Ravishankar <
khire...@redhat.com> wrote:

> I have a different problem. clang is complaining on the 4.1 back port of a
> patch which is merged in master before
> clang-format is brought in. Is there a way I can get smoke +1 for 4.1 as
> it won't be neat to have clang changes
> in 4.1 and not in master for same patch. It might further affect the clean
> back ports.
>
>
This is a bug.. please file an 'project-infrastructure' bug to disable
clang-format job in release branches (other than release-5 branch).

-Amar


> - Kotresh HR
>
> On Tue, Sep 18, 2018 at 2:13 PM, Ravishankar N 
> wrote:
>
>>
>>
>> On 09/18/2018 02:02 PM, Hari Gowtham wrote:
>>
>>> I see that the procedure mentioned in the coding standard document is
>>> buggy.
>>>
>>> git show --pretty="format:" --name-only | grep -v "contrib/" | egrep
>>> "*\.[ch]$" | xargs clang-format -i
>>>
>>> The above command edited the whole file. which is not supposed to happen.
>>>
>> It works fine on fedora 28 (clang version 6.0.1). I had the same problem
>> you faced on fedora 26 though, presumably because of the older clang
>> version.
>> -Ravi
>>
>>
>>
>>> +1 for the readability of the code having been affected.
>>> On Mon, Sep 17, 2018 at 10:45 AM Amar Tumballi 
>>> wrote:
>>>


 On Mon, Sep 17, 2018 at 10:00 AM, Ravishankar N 
 wrote:

>
> On 09/13/2018 03:34 PM, Niels de Vos wrote:
>
>> On Thu, Sep 13, 2018 at 02:25:22PM +0530, Ravishankar N wrote:
>> ...
>>
>>> What rules does clang impose on function/argument wrapping and
>>> alignment? I
>>> somehow found the new code wrapping to be random and highly
>>> unreadable. An
>>> example of 'before and after' the clang format patches went in:
>>> https://paste.fedoraproject.org/paste/dC~aRCzYgliqucGYIzxPrQ
>>> Wondering if
>>> this is just me or is it some problem of spurious clang fixes.
>>>
>> I agree that this example looks pretty ugly. Looking at random changes
>> to the code where I am most active does not show this awkward
>> formatting.
>>
>
> So one of my recent patches is failing smoke and clang-format is
> insisting [https://build.gluster.org/job/clang-format/22/console] on
> wrapping function arguments in an unsightly manner. Should I resend my
> patch with this new style of wrapping ?
>
> I would say yes! We will get better, by changing options of
 clang-format once we get better options there. But for now, just following
 the option suggested by clang-format job is good IMO.

 -Amar

 Regards,
> Ravi
>
>
>
> However, I was expecting to see enforcing of the
>> single-line-if-statements like this (and while/for/.. loops):
>>
>>   if (need_to_do_it) {
>>do_it();
>>   }
>>
>> instead of
>>
>>   if (need_to_do_it)
>>do_it();
>>
>> At least the conversion did not take care of this. But, maybe I'm
>> wrong
>> as I can not find the discussion in https://bugzilla.redhat.com/15
>> 64149
>> about this. Does someone remember what was decided in the end?
>>
>> Thanks,
>> Niels
>>
>
>

 --
 Amar Tumballi (amarts)
 ___
 Gluster-devel mailing list
 Gluster-devel@gluster.org
 https://lists.gluster.org/mailman/listinfo/gluster-devel

>>>
>>>
>>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Thanks and Regards,
> Kotresh H R
>



-- 
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Clang-Formatter for GlusterFS.

[Kotresh Hiremath Ravishankar]

I have a different problem. clang is complaining on the 4.1 back port of a
patch which is merged in master before
clang-format is brought in. Is there a way I can get smoke +1 for 4.1 as it
won't be neat to have clang changes
in 4.1 and not in master for same patch. It might further affect the clean
back ports.

- Kotresh HR

On Tue, Sep 18, 2018 at 2:13 PM, Ravishankar N 
wrote:

>
>
> On 09/18/2018 02:02 PM, Hari Gowtham wrote:
>
>> I see that the procedure mentioned in the coding standard document is
>> buggy.
>>
>> git show --pretty="format:" --name-only | grep -v "contrib/" | egrep
>> "*\.[ch]$" | xargs clang-format -i
>>
>> The above command edited the whole file. which is not supposed to happen.
>>
> It works fine on fedora 28 (clang version 6.0.1). I had the same problem
> you faced on fedora 26 though, presumably because of the older clang
> version.
> -Ravi
>
>
>
>> +1 for the readability of the code having been affected.
>> On Mon, Sep 17, 2018 at 10:45 AM Amar Tumballi 
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 17, 2018 at 10:00 AM, Ravishankar N 
>>> wrote:
>>>

 On 09/13/2018 03:34 PM, Niels de Vos wrote:

> On Thu, Sep 13, 2018 at 02:25:22PM +0530, Ravishankar N wrote:
> ...
>
>> What rules does clang impose on function/argument wrapping and
>> alignment? I
>> somehow found the new code wrapping to be random and highly
>> unreadable. An
>> example of 'before and after' the clang format patches went in:
>> https://paste.fedoraproject.org/paste/dC~aRCzYgliqucGYIzxPrQ
>> Wondering if
>> this is just me or is it some problem of spurious clang fixes.
>>
> I agree that this example looks pretty ugly. Looking at random changes
> to the code where I am most active does not show this awkward
> formatting.
>

 So one of my recent patches is failing smoke and clang-format is
 insisting [https://build.gluster.org/job/clang-format/22/console] on
 wrapping function arguments in an unsightly manner. Should I resend my
 patch with this new style of wrapping ?

 I would say yes! We will get better, by changing options of
>>> clang-format once we get better options there. But for now, just following
>>> the option suggested by clang-format job is good IMO.
>>>
>>> -Amar
>>>
>>> Regards,
 Ravi



 However, I was expecting to see enforcing of the
> single-line-if-statements like this (and while/for/.. loops):
>
>   if (need_to_do_it) {
>do_it();
>   }
>
> instead of
>
>   if (need_to_do_it)
>do_it();
>
> At least the conversion did not take care of this. But, maybe I'm wrong
> as I can not find the discussion in https://bugzilla.redhat.com/15
> 64149
> about this. Does someone remember what was decided in the end?
>
> Thanks,
> Niels
>


>>>
>>> --
>>> Amar Tumballi (amarts)
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Thanks and Regards,
Kotresh H R
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Clang-Formatter for GlusterFS.

[Ravishankar N]

On 09/18/2018 02:02 PM, Hari Gowtham wrote:

I see that the procedure mentioned in the coding standard document is buggy.

git show --pretty="format:" --name-only | grep -v "contrib/" | egrep
"*\.[ch]$" | xargs clang-format -i

The above command edited the whole file. which is not supposed to happen.
It works fine on fedora 28 (clang version 6.0.1). I had the same problem 
you faced on fedora 26 though, presumably because of the older clang 
version.

-Ravi



+1 for the readability of the code having been affected.
On Mon, Sep 17, 2018 at 10:45 AM Amar Tumballi  wrote:



On Mon, Sep 17, 2018 at 10:00 AM, Ravishankar N  wrote:


On 09/13/2018 03:34 PM, Niels de Vos wrote:

On Thu, Sep 13, 2018 at 02:25:22PM +0530, Ravishankar N wrote:
...

What rules does clang impose on function/argument wrapping and alignment? I
somehow found the new code wrapping to be random and highly unreadable. An
example of 'before and after' the clang format patches went in:
https://paste.fedoraproject.org/paste/dC~aRCzYgliqucGYIzxPrQ Wondering if
this is just me or is it some problem of spurious clang fixes.

I agree that this example looks pretty ugly. Looking at random changes
to the code where I am most active does not show this awkward
formatting.


So one of my recent patches is failing smoke and clang-format is insisting 
[https://build.gluster.org/job/clang-format/22/console] on wrapping function 
arguments in an unsightly manner. Should I resend my patch with this new style 
of wrapping ?


I would say yes! We will get better, by changing options of clang-format once 
we get better options there. But for now, just following the option suggested 
by clang-format job is good IMO.

-Amar


Regards,
Ravi




However, I was expecting to see enforcing of the
single-line-if-statements like this (and while/for/.. loops):

  if (need_to_do_it) {
   do_it();
  }

instead of

  if (need_to_do_it)
   do_it();

At least the conversion did not take care of this. But, maybe I'm wrong
as I can not find the discussion in https://bugzilla.redhat.com/1564149
about this. Does someone remember what was decided in the end?

Thanks,
Niels





--
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel





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

Re: [Gluster-devel] Clang-Formatter for GlusterFS.

[Hari Gowtham]

I see that the procedure mentioned in the coding standard document is buggy.

git show --pretty="format:" --name-only | grep -v "contrib/" | egrep
"*\.[ch]$" | xargs clang-format -i

The above command edited the whole file. which is not supposed to happen.

+1 for the readability of the code having been affected.
On Mon, Sep 17, 2018 at 10:45 AM Amar Tumballi  wrote:
>
>
>
> On Mon, Sep 17, 2018 at 10:00 AM, Ravishankar N  
> wrote:
>>
>>
>> On 09/13/2018 03:34 PM, Niels de Vos wrote:
>>>
>>> On Thu, Sep 13, 2018 at 02:25:22PM +0530, Ravishankar N wrote:
>>> ...

 What rules does clang impose on function/argument wrapping and alignment? I
 somehow found the new code wrapping to be random and highly unreadable. An
 example of 'before and after' the clang format patches went in:
 https://paste.fedoraproject.org/paste/dC~aRCzYgliqucGYIzxPrQ Wondering if
 this is just me or is it some problem of spurious clang fixes.
>>>
>>> I agree that this example looks pretty ugly. Looking at random changes
>>> to the code where I am most active does not show this awkward
>>> formatting.
>>
>>
>> So one of my recent patches is failing smoke and clang-format is insisting 
>> [https://build.gluster.org/job/clang-format/22/console] on wrapping function 
>> arguments in an unsightly manner. Should I resend my patch with this new 
>> style of wrapping ?
>>
>
> I would say yes! We will get better, by changing options of clang-format once 
> we get better options there. But for now, just following the option suggested 
> by clang-format job is good IMO.
>
> -Amar
>
>>
>> Regards,
>> Ravi
>>
>>
>>
>>>
>>> However, I was expecting to see enforcing of the
>>> single-line-if-statements like this (and while/for/.. loops):
>>>
>>>  if (need_to_do_it) {
>>>   do_it();
>>>  }
>>>
>>> instead of
>>>
>>>  if (need_to_do_it)
>>>   do_it();
>>>
>>> At least the conversion did not take care of this. But, maybe I'm wrong
>>> as I can not find the discussion in https://bugzilla.redhat.com/1564149
>>> about this. Does someone remember what was decided in the end?
>>>
>>> Thanks,
>>> Niels
>>
>>
>
>
>
> --
> Amar Tumballi (amarts)
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel



-- 
Regards,
Hari Gowtham.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel