[Gluster-devel] RFC: Gluster.Next: Where and how DHT2 work/code would be hosted

[Jeff Darcy]

On October 29, 2015 at 8:42:50 PM, Shyam (srangana at redhat.com) 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.