[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)
> <https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#bj-link0>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