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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
