[Gluster-devel] Invitation: Coding Standard: Automation @ Mon Apr 23, 2018 6pm - 6:50pm (IST) (gluster-devel@gluster.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20180423T123000Z DTEND:20180423T132000Z DTSTAMP:20180420T104809Z ORGANIZER;CN=atumb...@redhat.com:mailto:atumb...@redhat.com UID:0lg6ib7qjkumf6ftr90lh33...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=j...@pl.atyp.us;X-NUM-GUESTS=0:mailto:j...@pl.atyp.us ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=nb...@redhat.com;X-NUM-GUESTS=0:mailto:nig...@redhat.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=srang...@redhat.com;X-NUM-GUESTS=0:mailto:srang...@redhat.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=gluster-devel@gluster.org;X-NUM-GUESTS=0:mailto:gluster-devel@glust er.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=atumb...@redhat.com;X-NUM-GUESTS=0:mailto:atumb...@redhat.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=jaher...@redhat.com;X-NUM-GUESTS=0:mailto:jaher...@redhat.com CREATED:20180420T104809Z DESCRIPTION:BJ: \;https://bluejeans.com/205933580We will talk a nd come to agreement on \;https://bugzilla.redhat.com/show_bug.cgi?id=1 564149It was agreed that we will go ahead with format change automa tion\, 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\, an d also fix the codebase to get the formats.Pre-work if you are inte rested\, read about : https://clang.llvm.org/docs/ClangFormatStyleOptions.h tmlAlso 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 most ly agree: !AllowS hortIfStatementsOnASingleLine !AllowShortLoopsOnASingleLine BraceWrapping(! AfterControlStatement) BraceWrapping(AfterFunction) BraceWrapping(!BeforeEl se) ColumnLimit(80) IndentWidth(4) PointerAlignment(PAS_Right) SpaceBeforeP arens(SBPO_Always) TabWidth(8) UseTab(UT_Never) BinPackParameters=true AlignEscapedNewLinesLeft=false AlignConsecutiveDeclarations=true AlignConsecutiveAssignments= true AlwaysB reakAfterReturnType = trueMore options which we can discuss:< br>!IndentCaseLabelsSpaceBefore Parens = 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 per sonally feel moving \; https://github.com/amarts/glusterfs/commits/git- based-history-from-historic\, as a separate branch in gluster/glusterfs wou ld help. Again\, today people has to switch repositories for this.\n\n-::~: ~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: :~:~::-\nPlease do not edit this section of the description.\n\nView your e vent at https://www.google.com/calendar/event?action=VIEW&eid=MGxnNmliN3Fqa 3VtZjZmdHI5MGxoMzM3YXAgZ2x1c3Rlci1kZXZlbEBnbHVzdGVyLm9yZw&tok=MTkjYXR1bWJhb GxAcmVkaGF0LmNvbWU5MjY1N2M0N2YzNGJiZWViZjY3MTI1ODk1MmQ5YmU5YmI3ZDg3MjA&ctz= Asia%2FCalcutta&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20180420T104809Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Coding Standard: Automation TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] More on 'SpecApproved' and 'DocApproved'.
> > - github flag enforcement for all features (doc and spec requirement) > [amar] > I tried to add these details to 'glusterdocs' repo [1], but noticed that we don't talk much about github is used for 'RFE' itself there. So, to unblock developers for the branching of 4.1 by information planning to write the email with details. will fix the other docs soon(ish)- Any help here would be appreciated with *Gluster Swags*. The intention behind making these flags mandatory is explained in my earlier email [2]. As the same is now enforced, more details below. If any one of the 'DocApproved', 'SpecApproved' label is missing, the 'smoke' test name 'comment-on-issue' [3] would keep failing, if your commit message as a reference to github issues. *What is 'DocApproved' and how to get this?* Doc Approved means, the data required for 'user' to use the feature (all the options, CLI commands, how to setup etc) are provided, and also brief note of what the feature is about, is written down, so the release lead can just pick this information, and use it in release process. (Note, the idea is to automate this too, so release-lead's role is to control the cherry-picking after the branch-out). We would consider a blog with all these points also can be considered for this. *What is 'SpecApproved' and how to get this label?* Spec (or Specification) deals with the design of the feature, (mostly similar to gluster-spec repo we have). Answer the question of who needs it and why? (Detail on the usecase). How (for developers) part of the design explained. *Who / How to set this label ?* Today, anyone who is member of glusterfs project, and has access to set/unset labels can do it. But the advise is to leave it to general architects listed in the MAINTAINERS file, mainly as there may be few more questions pending on the spec. Also, as a top level guideline to the architects, please write a summary of why you are giving this label, what are the things you considered etc, without which there may be some conflict of interests here. Initial few days/weeks, I along with Shyam would closely monitor this label business. Every one is free to ask more question to developers if design is not clear. In future, like many other projects, we want to automate it, where the label is give after certain 'comment commands' are given (like 3 people giving 'i approve' type of message in issue would automatically get it the label). *What if I have more questions? or improvement suggestion?* Please ask, file a bug, write email.. there are many options. Improvements come only when people suggest / provide feedback etc. Regards, Amar [1] - https://github.com/gluster/glusterdocs [2] - http://lists.gluster.org/pipermail/gluster-devel/2018-April/054696.html [3] - https://build.gluster.org/job/comment-on-issue/ ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] tendrl-release v1.6.3 (milestone-5 2018) is available
The Tendrl team is happy to present tendrl-release v1.6.3 (milestone-5 2018) Install docs: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.6.3-(install-guide) Metrics: https://github.com/Tendrl/documentation/wiki/Metrics Changelog Backend: - Support gluster nodes/bricks with fqdn, IP and short names - Pack/Unpack entire Tendrl object during write/read to/from etcd, earlier each attribute of the object required its own http request for write/read to/from etcd. - Support for Cluster short names/alias - Improved log/alert/notification messages - https://github.com/Tendrl/commons/milestone/6 - https://github.com/Tendrl/node-agent/milestone/6 - https://github.com/Tendrl/gluster-integration/milestone/5 - https://github.com/Tendrl/monitoring-integration/milestone/5 API: - https://github.com/Tendrl/api/milestone/5 - Object marshalling/unmarshalling to/from etcd - Allow short_name as an attribute for cluster UI: - https://github.com/Tendrl/ui/milestone/5 Next Release: - Unmanage cluster per node - Prometheus Support - GD2 Support ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Coverity covscan for 2018-04-20-408a6d07 (master branch)
GlusterFS Coverity covscan results are available from http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-04-20-408a6d07 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
