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

[Jeff Darcy]

> 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.

I'm OK with that being true in a release branch, but I oppose any
mandate to undo work that has already been done on master.  That's
a waste of time, as such work will just have to be re-done, plus
extra merges as things get out of sync.  Forcing people to do work
in separate branches or repos violates the "land quickly" advice in
the glusterfs-specs README.md that still describes much of this
process.  Are you retracting your +1 on that?  I still think it's
good advice, based on our own experience and others'.  We should
*encourage* people to get stuff onto master, so long as it doesn't
break things that already work.  In the long run, it minimizes the
merge-and-resubmit busy-work that already slows our development.

If you want to remove/disable experimental code *in the 3.8 branch*
then knock yourself out.  I'll even help you do it.  Any attempt to
do the same on master will get a quick -2.