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

[Vijay Bellur]

On Friday 09 October 2015 10:39 PM, Shyam wrote:
> 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
>
>

Thanks Shyam, this seems like the right approach to me for all ongoing 
development. Over time we could also establish graduation criterion from 
experimental to mainline.

I wonder if glusterd2 could also be a different directory in 
experimental/. We could add a new configure option, say something like 
--enable-glusterd2, that compiles & installs glusterd2 instead of the 
existing glusterd. Thoughts?

Regards,
Vijay