all - as you can see the RC vote thread is out.  I'll send the
customary vote thread helper e-mail in a sec.

Oleg - i am pretty sure i captured your two kafka patches properly but
if you can verify they look good on the ticket that would be great.

Thanks
Joe

On Sat, Dec 19, 2015 at 8:09 AM, Oleg Zhurakousky
<[email protected]> wrote:
> I agree, I think we discussed it before and the Kafka upgrade doesn't belong 
> in 41
>
> Sent from my iPhone
>
>> On Dec 18, 2015, at 23:26, Sean Busbey <[email protected]> wrote:
>>
>> with the Kafka client change backed out for 0.5.0, I'm good to go with
>> 0.4.1 on the rest of the changes.
>>
>>> On Fri, Dec 18, 2015 at 10:11 PM, Joe Witt <[email protected]> wrote:
>>> Sean,
>>>
>>> Yeah i don't disagree with that point.  The caveat being it was only a
>>> change to that client not a change to support the new client API and
>>> the behavior with existing clients old and new verified.
>>>
>>> I'd prefer to stick with 0.4.1 and if you still think it is best to
>>> actually just revert that commit and apply it toward 0.5.0.
>>>
>>> What do you think?
>>>
>>> Thanks
>>> Joe
>>>
>>>> On Fri, Dec 18, 2015 at 11:08 PM, Sean Busbey <[email protected]> wrote:
>>>> Can we update to 0.5.0 instead? The kafka client change isn't
>>>> something I'd expect in a patch release.
>>>>
>>>>> On Fri, Dec 18, 2015 at 9:54 PM, Joe Witt <[email protected]> wrote:
>>>>> ok - so master is presently on 041 and it does indeed appear to be all
>>>>> incremental friendly fixes.  So looks like we can just use the normal
>>>>> process.  As excited as I was to use cherry-pick doesn't look like it
>>>>> is needed.
>>>>>
>>>>> The bugs fixed on 041 so far are all nice cleanup items and things
>>>>> which have been problematic for quite a while.  However, there are a
>>>>> few site-to-site issues that would create some pretty annoying issues
>>>>> for users so best to eliminate them.  And big thanks to Matt Clarke
>>>>> for finding and reporting them!
>>>>>
>>>>> Gonna prep an RC.
>>>>>
>>>>> Thanks
>>>>> Joe
>>>>>
>>>>>> On Thu, Dec 17, 2015 at 7:53 PM, Tony Kurc <[email protected]> wrote:
>>>>>> I have no objection to "because we should be able to do this well!" as a
>>>>>> reason.
>>>>>>
>>>>>> On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Generally RCs are used to address that level of validation, so in the 
>>>>>>> end
>>>>>>> I still think it's a more of a culture one chooses. One common  example;
>>>>>>> x.x.1+ = maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major
>>>>>>> features.
>>>>>>>
>>>>>>> In any event IMHO the ability to quickly release maintenance releases is
>>>>>>> very important  as it showcases our attention to quality
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On Dec 17, 2015, at 19:32, Tony Kurc <[email protected]> wrote:
>>>>>>>>
>>>>>>>> I'm not sure I understand "more validation" reasoning - won't features 
>>>>>>>> at
>>>>>>>> the end have very little validation?
>>>>>>>>
>>>>>>>>> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>> Another reason to release 0.4.1 is to allow the additions that warrant
>>>>>>>>> 0.5.0 to have more validation before release. With a regular release
>>>>>>> cycle,
>>>>>>>>> features can go in at the beginning to have more time for catching 
>>>>>>>>> bugs
>>>>>>> in
>>>>>>>>> them. I also agree with what Sean said below.
>>>>>>>>>
>>>>>>>>> rb
>>>>>>>>>
>>>>>>>>>> On 12/17/2015 04:00 PM, Sean Busbey wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc <[email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>> s/features/buxfixes/
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc <[email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
>>>>>>>>>>>> features onto 0.4.1?
>>>>>>>>>> This is a good question.
>>>>>>>>>>
>>>>>>>>>> Some downstream users might have different change processes for a
>>>>>>> patch vs
>>>>>>>>>> minor release, so making a 0.4.1 that fixes what we determine to be a
>>>>>>>>>> substantial gap in the 0.4 line would be nice for them.
>>>>>>>>>>
>>>>>>>>>> While we might be a young project now, it would be good to already 
>>>>>>>>>> have
>>>>>>>>>> the
>>>>>>>>>> habit practiced for when we have more users in enterprise settings.
>>>>>>>>>>
>>>>>>>>>> On the other hand, 0.4.0 just happened, so a release in 3 days would
>>>>>>>>>> minimize the number of "stuck on 0.4.0" folks.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ryan Blue
>>>>>>>>> Software Engineer
>>>>>>>>> Cloudera, Inc.
>>
>>
>>
>> --
>> Sean
>>

Reply via email to