On 10/29/2015 01:42 AM, Avra Sengupta wrote:
My 2 cents on this:
The decision we take on this should have certain rationale, and I see
two key things affecting that decision.
1. How much of the code we are planning to write now, is going to make
it to the final product. If we are sure that a sizeable amount of code
we are writing now, is gonna change over the course of time, then it
makes sense to have that kinda development in experimental branch.
2. Is the code we are planning to deliver meddle with existing
infrastructure. If so, then it should definitely go into experimental
Now analyzing NSR based on the above two constraints :
1. We definitely plan to use more than 80% of the code we write now, and
plan to go about it in an incremental module by module kinda way.
2. We hardly have any overlap with existing infrastructure, and we can
easily integrate with the current glusterd now, and move on to Glusterd
2, as and when it is ready for consumption.
Based on the above analysis, I would say NSR can go right into master,
and we can easily make sure that it's not built as part of any release.
Now what NSR would follow, isn;t necessary for other translators to
follow. For eg. I would think Glusterd2 would have to be in experimental
coz it might meddle with current glusterd (but Atin would know better).
The point being, the decision we take need not be a collective decision
for all components, that would be enforced as a process, but rather
should be a decision taken by individual components based on merit.
Will code that NSR puts up in master be ready to ship when 3.8 is branched?
I ask the above, as I think we need a *process*, and not an open ended
"put it where you want option", for the following reasons,
- Something that ships experimental is not to be consumed in production,
so till the point an/any effort is ready it can be housed in experimental
- It is not about how much of infra code is impacted, or how much code
would change, it is about readiness of the functionality
- The intention is also to keep such WIP xlators segregated in master
- It is easy to control the "don't build/ship" directive for everything
under experimental, rather than make these decisions at a per
directory/xlator/module level
- It is a clear message for anyone picking up these pieces to deploy and
play with etc.
Coming to DHT2, irrespective of reason (1) above, all other reasons for
which NSR can stay outside of experimental holds good for DHT2 as well.
I would leave others to comment if NSR gets into experimental or not,
and what is the due diligence we need in this case.
So are we going ahead with experimental as a process? I am punting this
to Vijay and Jeff :)
On 10/28/2015 08:32 PM, Shyam wrote:
Sending this along again.
- Are we decided on *experimental*?
- If so, what else needs attention in the patch below?
- (Re)views please... (views as in "What are your views on this?", not
"Have you viewed this?" ;) )
Shyam
On 10/12/2015 02:18 PM, Shyam wrote:
In an effort to push this along, update the change with suggested edits
and comments till now, request a review and further comments so that we
make this official at some (sooner) point in time.
http://review.gluster.org/#/c/12321/2
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
