On October 29, 2015 at 8:42:50 PM, Shyam (srangana@xxxxxxxxxx) wrote: > I assume this is about infra changes (as the first 2 points are for > some reason squashed in my reader). I think what you state is infra > (or other non-experimental) code impact due to changes by > experimental/inprogress code, should be dealt with clearly and > carefully so as to not impact regular functionality. In which case I > *agree* and do not mean otherwise. > > I think this sort of goes back to what Niels commented on my squashing > a .patch and proposed using #define EXPERIMENTAL in this thread (or > such methods). Sort of, although I would prefer that the distinction be run-time instead of compile-time whenever possible. > > 3. All experimental functionality, whether in its own translator or > > otherwise, should be controlled by an option which is off by > > default. > > Ah! I think this is something akin to the "#define EXPERIMENTAL" > suggestion and non-experimental code impact I guess, right? I think so. Also, since I wasn’t clear before, I think there should be *separate* options per feature, not one blanket “experimental” option. For example, if you want to play with DHT you’d need to: (1) Install the gluster-experimental RPM (2) Tweak the glusterd script or volfile to allow experimental features (3) Set cluster.dht2 (or whatever) on your volume Note the absence of steps to download, hand-edit, or build anything yourself. I think that’s key: no risk if you don’t go out of your way to enable experimental code, but you don’t have to be a full-time Gluster developer to walk on the wild side. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
