On 10/29/2015 10:26 PM, Jeff Darcy wrote:
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.
Agreed
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.
Agreed.
One more question, should we package all experimental code in the
future, or things that reach a certain level of experimental maturity?
As an example, say DHT2 has 3 FOPs only implemented when we do *some
release*, should we package it, or leave it behind? Asking as I am
unsure of the course, or maybe a consideration for the future.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
