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

[Shyam]

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