Patches for MRv1 - where to commit?

[Todd Lipcon <to...@cloudera.com>]

Hey all,

Now that MR2 is in trunk and 0.23, but we're still maintaining it in
0.20.20x, what's the correct protocol for fixes when the component no
longer is used in trunk? Must we contribute patches for trunk as well
as 20x, if we plan to commit to 20x, so that people might backport to
22 or 21? Or can we assume that providing a patch for 0.20.20x is
enough, and if anyone wants to put it in 21 or 22, they will
forward-port?

Of course library or client fixes should go in trunk - I'm just
talking about changes to JT or one of the schedulers.

Thanks
-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Patches for MRv1 - where to commit?

[Todd Lipcon <to...@cloudera.com>]

OK, I just wanted to confirm. Thanks! I commented on 2736 that we
should also remove fairsched and cap sched from trunk.

-Todd

On Fri, Sep 16, 2011 at 3:35 PM, Eli Collins <el...@cloudera.com> wrote:
> On Fri, Sep 16, 2011 at 3:30 PM, Arun C Murthy <ac...@hortonworks.com> wrote:
>>
>> On Sep 16, 2011, at 3:25 PM, Todd Lipcon wrote:
>>
>>> Hey all,
>>>
>>> Now that MR2 is in trunk and 0.23, but we're still maintaining it in
>>> 0.20.20x, what's the correct protocol for fixes when the component no
>>> longer is used in trunk? Must we contribute patches for trunk as well
>>> as 20x, if we plan to commit to 20x, so that people might backport to
>>> 22 or 21? Or can we assume that providing a patch for 0.20.20x is
>>> enough, and if anyone wants to put it in 21 or 22, they will
>>> forward-port?
>>>
>>
>> +1, I thought we agreed that there is no point committing to trunk when we aren't going to maintain it.
>>
>
> +1. That's my understanding as well.  Which reminds me, I'll get
> another patch up for MAPREDUCE-2736 today.
>
> Thanks,
> Eli
>
>
>> Arun
>>
>>> Of course library or client fixes should go in trunk - I'm just
>>> talking about changes to JT or one of the schedulers.
>>>
>>> Thanks
>>> -Todd
>>> --
>>> Todd Lipcon
>>> Software Engineer, Cloudera
>>
>>
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Patches for MRv1 - where to commit?

[Eli Collins <el...@cloudera.com>]

On Fri, Sep 16, 2011 at 3:30 PM, Arun C Murthy <ac...@hortonworks.com> wrote:
>
> On Sep 16, 2011, at 3:25 PM, Todd Lipcon wrote:
>
>> Hey all,
>>
>> Now that MR2 is in trunk and 0.23, but we're still maintaining it in
>> 0.20.20x, what's the correct protocol for fixes when the component no
>> longer is used in trunk? Must we contribute patches for trunk as well
>> as 20x, if we plan to commit to 20x, so that people might backport to
>> 22 or 21? Or can we assume that providing a patch for 0.20.20x is
>> enough, and if anyone wants to put it in 21 or 22, they will
>> forward-port?
>>
>
> +1, I thought we agreed that there is no point committing to trunk when we aren't going to maintain it.
>

+1. That's my understanding as well.  Which reminds me, I'll get
another patch up for MAPREDUCE-2736 today.

Thanks,
Eli


> Arun
>
>> Of course library or client fixes should go in trunk - I'm just
>> talking about changes to JT or one of the schedulers.
>>
>> Thanks
>> -Todd
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>
>

Re: Patches for MRv1 - where to commit?

[Arun C Murthy <ac...@hortonworks.com>]

On Sep 16, 2011, at 3:25 PM, Todd Lipcon wrote:

> Hey all,
> 
> Now that MR2 is in trunk and 0.23, but we're still maintaining it in
> 0.20.20x, what's the correct protocol for fixes when the component no
> longer is used in trunk? Must we contribute patches for trunk as well
> as 20x, if we plan to commit to 20x, so that people might backport to
> 22 or 21? Or can we assume that providing a patch for 0.20.20x is
> enough, and if anyone wants to put it in 21 or 22, they will
> forward-port?
> 

+1, I thought we agreed that there is no point committing to trunk when we aren't going to maintain it.

Arun

> Of course library or client fixes should go in trunk - I'm just
> talking about changes to JT or one of the schedulers.
> 
> Thanks
> -Todd
> -- 
> Todd Lipcon
> Software Engineer, Cloudera