> 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. _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
