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