Re: [Gluster-Maintainers] [Gluster-devel] Maintainers meeting Agenda: Dec 13th

[Niels de Vos]

On Tue, Dec 12, 2017 at 06:45:21AM -0500, Amar Tumballi wrote:
> This is going to be a longer meeting if we want to discuss everything here,
> so please consider going through this before and add your points (with
> name) in the meeting notes. See you all tomorrow.
> 
> Meeting date: 12/13/2017 (Dec 13th, 19:30IST, 14:00UTC, 09:00EST)
> BJ
...
> For features
> 
>- Clearly ask the questions (ie, these are part of gluster specs)
> 
>   Ask about monitoring
>   Ask about events
>   Ask about test cases
>   Ask about supporting / debugging
>   Ask about path from alpha to beta to GA for the feature.
>   Ask for contact person
>   Ask about release-notes
>   Usecase / impact areas

A description of the requirements for the feature and technical design
seem to be missing? Do we still expect to see the features documented in
the glusterfs-specs repositry?
  
https://github.com/gluster/glusterfs-specs#the-flow-of-an-idea-from-your-head-to-implementation

...
> Round Table
> 
>- [Amar] Do we need a STM release in future? ie, after above process is
>done.
>   - STM’s main goal is to say the release is not good to be supported,
>   we are using this release to add feature, and will stabilize it
> by next LTM.
>   - With introduction of ‘experimental’ branch, and a proper streamline
>   of process where documentation and tests are also landed with feature, 
> it
>   may be fine to say feature is ready.
>   - Also say only if line-coverage is above certain limit, then only it
>   will figure out in release-notes.

STM releases were introduced to get new features out to users for
testing so the developers can get early feedback. With the 6 month cycle
for LTM releases, developers were complaining that users can not be
convinced to test the nightly builds, and hence no feedback was given
until a beta release was produced. The months delay between implementing
the feature and getting feedback was difficult to handle.

I guess we could use the experimental branch for building packages that
users can try out. But I do not expect users perceive this as tempting
way to try out a certain new feature.

HTH,
Niels
___
maintainers mailing list
maintainers@gluster.org
http://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] Maintainers meeting Agenda: Dec 13th

[Atin Mukherjee]

On Tue, Dec 12, 2017 at 5:15 PM, Amar Tumballi  wrote:

> This is going to be a longer meeting if we want to discuss everything
> here, so please consider going through this before and add your points
> (with name) in the meeting notes. See you all tomorrow.
>
> Meeting date: 12/13/2017 (Dec 13th, 19:30IST, 14:00UTC, 09:00EST)
> BJ
> Link
>
>- Bridge: https://bluejeans.com/205933580
>- Download: 
>
>
> 
> Attendance
>
>- [Sorry Note] - 
>
>
> 
> Agenda
>
>-
>
>Any AI from previous meeting?
>-
>
>Process Automation proposal
>- [WHY]
>  - We should have processes to help fast track the project’s
>  progress
>  - Any new contributor should find the steps non-confusing
>  - If it is not enforced in the process, no guidelines would be
>  enforced in practise
>  - If any developer is ‘spending extra time’ to follow the
>  process, it is not a good sign for the project
>   - [HOW]
>
>
> This
> is for everyone entering from github:
>
> For bugs
>
>- There is one liner in github issues by default (at the top) saying
>your bugs goto bugzilla.
>   - [One time activity] Change the current github issues default
>   msging to just give one line suggestion, instead of every detail.
>- If they still go ahead and create it, anyone triaging the issues
>marks it as ‘Type:Bug’
>   - [Manual] This human intervention expected in any ‘automation’. We
>   can do it as part of bug triage too.
>- Upon adding ‘Type:Bug’ tag, a bug is automatically created in
>bugzilla. Issue gets closed with URL to bugzilla ID, asking creator to
>refer bugzilla for further updates.
>   - [Automatic] Needs jenkins job (or other github automations)
>
> For questions
>
>- There is one liner in github issues by default (at the top - 1)
>saying your questions go into mailing list.
>   - [One time activity] Change the current github issues default
>   msging to just give one line suggestion, about mailing list.
>- If they still go ahead and create it, anyone triaging the issues
>marks it as ‘Question’
>   - [Manual] This human intervention expected in any ‘automation’. We
>   can do it as part of bug triage too.
>- Upon adding ‘Question’ tag, the question gets posted to mailing
>list, with creator in Cc, the archive URL gets posted to github, and the
>issue gets closed.
>   - [Automatic] Needs jenkins job (or other github automations)
>
> For features
>
>- Clearly ask the questions (ie, these are part of gluster specs)
>
>   Ask about monitoring
>   Ask about events
>   Ask about test cases
>   Ask about supporting / debugging
>   Ask about path from alpha to beta to GA for the feature.
>   Ask for contact person
>   Ask about release-notes
>   Usecase / impact areas
>
>
I expect the design doc to be also part of this checklist and a patch can
only be  'SpecApproved" if its corresponding design doc is already approved
and merged. There might be some features where all of the above may not be
applicable. So is it the maintainer's or the owner's responsibility to tick
the respective check box or mark them as N/A ?

>
>-
>
>Once user answers all these questions, provide ‘SpecApproved’ flag.
>
>
So this flag will be visible in the gerrit UI only when a patch has a
respective github issue id and the submit button will stay as disabled till
this flag is +1ed?


>-
>   - Only maintainers are allowed to provide this flag.
>-
>
>Ask developer to provide documentation. (Can be part of initial spec,
>if not can be followup question automatically posted after ‘specApproved’
>flag).
>-
>
>If provided give ‘DocApproved’ flag.
>
>
As I mentioned earlier, I'd think that we don't need this flag as it can be
part of the overall spec-list check.


>-
>   - Again, only maintainers are allowed to provide this flag.
>-
>
>For every patch in glusterfs project, (as part of smoke), run a test
>to see if a patch is for the feature, if yes (ie, a github issue is
>present), check if ‘SpecApproved’ and ‘DocApproved’ is present, and only
>then a feature gets +1 vote.
>- Expectation is every patch posted is either a bug fix or a feature.
>-
>
>Now Architects are approved to revert a patch which violates by either
>not having github issue nor bug-id, or uses a bug-id to get the feature in
>etc.
>- It is fine to revert a patch where SpecApproved and DocApproved is
>   given by the author of the patch, and