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

[Shyam]

On 10/09/2015 12:07 AM, Atin Mukherjee wrote:
> First of all my apologies for not going through the meeting blog before
> sending my thoughts on how we plan to maintain GlusterD 2.0 [1].
>
> This approach seems fine to me as long as we don't touch any existing
> xlators. How do we handle cases where other xlators get impacted by
> certain changes. Are we going to copy the whole translator in
> xlators/experimental and start working on it?

Nope, we should send a change request for that xlator as a separate 
commit when possible.

The counter example to this is, point (4) below (where DHT2 needs a bit 
of change in glusterd, but ...).

I suggest such changes be maintained as .patch files inside the xlator, 
till a point when this can be merged is decided.

>
> Instead of all this wouldn't it be simpler to have development under a
> separate branch say "4.0-unstable" and we could disable CI on this
> branch till it becomes stable? Are we worried about pulling in the
> changes from this to master once the branch becomes stable?

I guess the worry is *bulk* changes appearing in master (as per meeting 
minutes). I share the same concern as well (on bulk changes), but I am 
unsure of review stringency on experimental, as things will evolve here, 
than each commit be ready for a clean review from day 1. So, this is an 
open confusion in my head as well, as when we want to move an xlator 
from experimental to suported, what would be the criteria? Would we not 
be doing bulk reviews then as well?

What do others think?

>
> This is just my thought and I would like to get a clarity on this.
>
> Thanks,
> Atin
>
> [1] http://www.gluster.org/pipermail/gluster-devel/2015-October/046872.html
>
> On 10/08/2015 11:35 PM, Shyam wrote:
>> Hi,
>>
>> On checking yesterday's gluster meeting AIs and (later) reading the
>> minutes, for DHT2 here is what I gather and propose to do for $SUBJECT.
>> Feel free to add/negate any plans.
>>
>> (This can also be discussed at [2])
>>
>> -------------------------------------------------------------------
>> 1) Create a directory under the glusterfs master branch as follows,
>> ./xlators/*experimental*/dht2
>> ./xlators/*experimental*/posix2
>>
>> See patch request at [2]
>>
>> All code, design documents (work products in general) would go into this
>> directory.
>>
>> 2) Code that compiles and does not cause CI failures could *potentially*
>> be merged with very few DHT2 dev folks assent.
>>
>> There would possibly be no CI integration till we get something working,
>> so merges would be based on compile passing initially. Soon there would
>> be an attempt at getting unit testing integrated, so that code being
>> submitted is not abysmally horrendous
>>
>> 3) Common framework code changes (if any) would be presented as a
>> separate commit request
>>
>> 4) (Big problem) DHT2 requires glusterd changes to create a volume as
>> DHT2 and not DHT, this would be maintained as a .patch in the dht2
>> directory as above. This is so that people can play with DHT2 volumes if
>> interested. Integration of this piece either comes with glusterd 2.0 or
>> based on time lines of other events, in the current version of glusterd.
>> (if you are interested in seeing the current version of this patch, go
>> here [1])
>> -------------------------------------------------------------------
>>
>> If there is some key disagreement on certain points like (2) above, then
>> we would need to bring in DHT2 code in parts so that it makes sense.
>> This is fine too, just that we would have 2 repos till we reach a point
>> of maturity in development.
>>
>> -------------------------------------------------------------------
>> *Some issues with the approach:*
>> A) We need to ensure we do not ship xlators compiled from the
>> experimental directory
>>
>> B) We need to possibly add a buddy maintainer for experimental
>> translator owners, who can help with the process of merging their changes.
>>
>> C) I am not sure how this helps the review process, as initially xlator
>> development can be iffy and so we do not expect reviews to be stringent.
>> Later when we want to move this out of the experimental category, how do
>> we review the same now, and what actions do we take to ensure quality?
>> Won't we have the same bulk code review issue?
>> -------------------------------------------------------------------
>>
>> Shameless plug: For quality and if an xlator plays well with other parts
>> of gluster the distaf framework of testing against possible graphs and
>> access protocols can be of immense help.
>>
>> Shyam
>>
>> [1]
>> https://github.com/ShyamsundarR/glusterfs/commit/663eeb98f6a51384c8745b8882e7c6c4f7b58a7c
>>
>> [2] http://review.gluster.org/#/c/12321/1
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel