On Tue, Mar 22, 2016 at 12:19:56PM -0400, Jeff Darcy wrote: > > 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. The disabling and possible removing of features would only be done in the release-3.8 branch. There is no intention to remove the features that are not finished/stable from the master branch. I also prefer to see changes merged early on, and encourage all of the contributors to post them as soon as possible. It helps to get some more eyes over them and setup some automated testing. We need to make sure our master branch doesnt break when changes are made in common code, finding these problems early benefits everyone. Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
