[Gluster-devel] RFC: Gluster.Next: Where and how DHT2 work/code would be hosted

[Shyam]

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