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