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