rgr that - will revert, save patch on ticket, plus this means someone can get Oleg's kafka tester patch reviewed there too.
thanks On Fri, Dec 18, 2015 at 11:26 PM, 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
