On 10/09/2015 11:26 AM, Jeff Darcy wrote:
My position is that we should maximize visibility for other developers by doing
all work on review.gluster.org. If it doesn't affect existing tests, it should
even go on master. This includes:
* Minor changes (e.g. list.h or syncop.* in http://review.gluster.org/#/c/8913/)
* Refactoring that doesn't change functionality (e.g. all of
http://review.gluster.org/#/c/9411/)
* Translators that no existing test will enable (e.g. DHT2)
It's not hard to ensure that experimental translators get built but not shipped, just by
tweaking the specfile. I think it's something to do with "ghost" but maybe
someone who actually knows can just answer off the top of their head before I spend 10x
as much time investigating.
The really sticky case is incompatible changes to permanent infrastructure,
such as GlusterD 2. My preference for those to be on review.gluster.org as
well, but on a branch other than master. It's tempting to make other things
dependent on GlusterD 2 and put them on the branch as well, but IMO that
temptation should be avoided. Periodic merges from master onto the branch
*will* become a time sink, *especially* if other people are following the
advice above to make other changes on master. That's exactly what happened
with NSR before, and I don't think it will be any different this time or with
DHT2. It's really not *that* much work to make something compatible with
GlusterD 1 as well, and/or to make it selectable via an option. In the long
run, it's likely to be less work than either constant branch management or a
big-bang merge at the end.
Overall I am fine with the "experimental" on master, I think nothing
avoids a review problem better than having things in master. When
something move out of experimental, I think we should have had enough
eyes on the code, to make that last move less painful than what it is
today, i.e a big merge request.
So in short my vote is a +1 for the "experimental" manner of approaching
this, (esp. for DHT2).
Anyway, start of this would be this patch:
http://review.gluster.org/#/c/12321
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
