[Gluster-devel] 3.6 Feature Freeze - move to mid next week?

[Dan Lambright]

----- Original Message -----
> From: "Jeff Darcy" <jdarcy at redhat.com>
> To: "Vijay Bellur" <vbellur at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Friday, July 4, 2014 10:14:32 AM
> Subject: Re: [Gluster-devel] 3.6 Feature Freeze - move to mid next week?
> 
> > Given the holiday weekend in US, I feel that it would be appropriate
> > to move the 3.6 feature freeze date to mid next week so that we can
> > have more reviews done & address review comments too. We can still
> > continue to track other milestones as per our release schedule [1].
> > What do you folks think?
> 
> I think the answer depends on what we can expect to change between now
> and then.  Since the gluster.org feature page never got updated to
> reflect the real feature set for 3.6, I took the list from email sent
> after the planning meeting.
> 
>   * Better SSL
>     Two out of three patches merged, one still in review.
> 
>   * Data Classification
>     Design barely begun.
> 
>   * Heterogeneous Bricks
>     Patch has CR+1 V+1 but still stalled in review.
> 
>   * Trash
>     Ancient one is still there, probably doesn't even work.
> 
>   * Disperse
>     Patches still in very active review.
> 
>   * Persistent AFR Changelog Xattributes
>     Patches merged.
> 
>   * Better Peer Identification
>     Patch still in review (fails verification).
> 
>   * Gluster Volume Snapshot
>     Tons of patches merged, tons more still to come.
> 
>   * AFRv2
>     Jammed in long ago.
> 
>   * Policy Based Split-Brain Resolver (PBSBR)
>     No patches, feature page still says in design.
> 
>   * RDMA Improvements
>     No patches, feature page says work in progress.
> 
>   * Server-side Barrier Feature
>     Patches merged.
> 
> 
> That leaves us with a very short list of items that are likely to change
> state.
> 
>   * Better SSL
> 
>   * Heterogeneous Bricks
> 
>   * Disperse
> 
>   * Better Peer Identification
> 
> Of those, I think only disperse is likely to benefit from an extension.
> The others just need people to step up and finish reviewing them, which
> could happen today if there were sufficient will.  The real question is
> what to do about disperse.  Some might argue that it's already complete
> enough to go in, so long as its limitations are documented
> appropriately.  Others might argue that it's still months away from
> being usable (especially wrt performance).  In a way it doesn't matter,
> because either way a few days won't make a difference.  We just need to
> make a collective decision based on its current state (or close to it).
> If we need to wait a few days before people can come together for that,
> so be it.

The reliability and performance of the erasure code translator is probably not at a level where we could guarantee the feature is bug free and "ready". However the feature could be added to the gluster code base for people to begin to experiment with, as suggested we would need to document limitations. The idea being the more hands get on the code, the more bugs found, the more suggestions made for improvements, deeper integration, etc.  I do not believe the erasure code translator is called "disperse" any longer.


> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>