[Gluster-devel] [IMPORTANT] Release planning for GlusterFS 3.8, schedule, deadlines and all

[Niels de Vos]

On Mon, Mar 14, 2016 at 08:44:06PM +0530, Atin Mukherjee wrote:
> -Atin
> Sent from one plus one
> On 14-Mar-2016 6:45 pm, "Niels de Vos" <ndevos at redhat.com> wrote:
> >
> > On Mon, Mar 14, 2016 at 05:54:00PM +0530, Atin Mukherjee wrote:
> > >
> > >
> > > On 03/14/2016 02:49 PM, Niels de Vos wrote:
> > > > Hi,
> > > >
> > > > We're kicking the 3.8 release back into shape and schedule. Our
> planned
> > > > 6 month release cycle has completely failed on us, we're about 6
> months
> > > > behind. I've taken the liberty to set aggressive deadlines and put
> this
> > > > on the roadmap on https://www.gluster.org/community/roadmap/3.8/ .
> > > >
> > > > The page explains the dates, it will be extremely difficult to
> convince
> > > > me to change it. A delay because a feature is not ready will not be
> > > > acceptable, the feature will be moved out into the next (major/minor)
> > > > release.
> > > Is this applicable for all Gluster 4.0 initiatives as well? Since all of
> > > these will come as experimental features as part of 3.8 does feature
> > > freeze criteria apply for them?
> >
> > Yes, anything that is expected to be ready for experimental use should
> > fulfill all requirements. Gluster 4.0 features in 3.8 would need to be
> > usable and configurable by most of our users. Experimental features may
> > become fully stable and 'supported' during the 3.8 lifecycle.
> Given the experimental nature of 4.0 features, I was wondering how do we
> define the scope of readiness. Usable is the right term and none of these
> features should break legacy stuffs. I am little doubtful about the word
> "stable". Can stable and experimental go together? (Very few IMO)
> Let me know if you think otherwise.

"Stable" for me means that users should be able to configure and use it
with basic Gluster functionality and it does not break under moderate
workloads. Performance might be bad, or it may not work with all types
of volumes. The way to configure it should not heavily change in the
3.8.x lifetime. It also should be seen as a commitment to our users to
maintain the feature for the whole 3.8.x life, even when the next
release is ready in 6 months.

For most of the Gluster 4.0 features, I do not expect to see them as
part of glusterfs-3.8, not even as experimental. For being in the
experimental category, a feature needs to have a pretty complete
implementation, documentation and tests.

Features that are listed on the roadmap really need to show good
progress, otherwise they'll get marked as "at risk" and will be moved
out to the next release if the status does not change. This includes
removal of xlators, components and other bits from the sources
immediately after branching 3.8.

HTH,
Niels


> >
> > Features that are not in a usable or stable state, or do not provide any
> > of the other requirements will be stripped out of the 3.8 release.
> >
> > HTH,
> > Niels
> >
> >
> > > > Requirements that are listed on the roadmap affect all features. *ALL*
> > > > of these will need to be mostly fulfilled by the end of April. The
> last
> > > > day of April has been picked as branch date. Any feature that is not
> > > > ready at the time of branching (includes *ALL* requirements) will be
> > > > disabled/removed from the sources. There is an other chance to get the
> > > > feature in for the following release in 6 months time.
> > > >
> > > > All feature owners have been put on CC of this email. They need to go
> > > > through the roadmap and update the description, current status, links,
> > > > and any other missing parts before the end of this week. There need to
> > > > be visible progress on at least the contents in the roadmap, and in
> the
> > > > linked designs/feature pages. If there is no obvious attempt to
> improve
> > > > the status of the feature, it will be marked as "move to next
> release".
> > > >
> > > > Sending updates for the roadmap is easy, click the "Edit this page on
> > > > GitHub" link on the bottom of the page. It should create a pull
> request
> > > > that I can review, please assign it to me ("nixpanic" on GitHub).
> > > >
> > > > If a feature is not expected to be ready before the end of April,
> please
> > > > let me know as soon as possible. All tracking that we do makes it
> easier
> > > > when we are kept informed.
> > > >
> > > > For this release, Jiffin offered his assistance. If there are any
> > > > questions, do not hesitate to ask us (of course with the gluster-devel
> > > > list on CC).
> > > >
> > > > Thanks,
> > > > Jiffin & Niels
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Gluster-devel mailing list
> > > > Gluster-devel at gluster.org
> > > > http://www.gluster.org/mailman/listinfo/gluster-devel
> > > >
> >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160314/edd6b7e8/attachment.sig>