Hi Brock - what's involved? I'm relatively new to the Apache process but am willing to give it a go.
Cheers, Dave On 26 September 2012 16:18, Brock Noland <br...@cloudera.com> wrote: > OK great, it sounds like the release is on! Does anyone want to be the > Release Manager? I am more than willing to be the RM if no one else > is interested, but as I have done it a few time times I won't feel too > bad if someone else wants to. ;) > > Brock > > On Mon, Sep 24, 2012 at 7:28 AM, Jim Donofrio <donofrio...@gmail.com> wrote: >> I wont -1 it but I wont +1 it either. I would rather save major revision >> changes for more drastic api changes but we need to cut this release so I >> wont get in the way. Lets cut a release candidate on Oct 1 as we talked >> about before. >> >> >> On 09/24/2012 04:55 AM, James Kinley wrote: >>> >>> +1 to major release with MRUNIT-138. >>> >>> James. >>> >>> On 24 Sep 2012, at 09:21, Dave Beech <dbe...@apache.org> wrote: >>> >>>> Hi Brock >>>> Same here - I would be happy to see a major version release with >>>> MRUNIT-138 included. >>>> Cheers >>>> Dave >>>> >>>> On 24 September 2012 07:35, Jarek Jarcec Cecho <jar...@apache.org> wrote: >>>>> >>>>> Hi Brock, >>>>> thank you for your summary. I'm fine with the idea and I won't -1 it. >>>>> >>>>> Jarcec >>>>> >>>>> On Sat, Sep 22, 2012 at 07:48:16AM -0500, Brock Noland wrote: >>>>>> >>>>>> It feels like we approaching a consensus on that if we include >>>>>> MRUNIT-138, which is backwards incompatible but an improved user API, >>>>>> we should bump the major version. Assuming MRUNIT-138 is included, is >>>>>> there anyone that would -1 a release with the 1.0 designation? >>>>>> >>>>>> Brock >>>>>> >>>>>> On Thu, Sep 13, 2012 at 11:42 AM, Brock Noland <br...@cloudera.com> >>>>>> wrote: >>>>>>> >>>>>>> I agree that the changes in this release are not nearly as substantial >>>>>>> as handling the Tool interface but I do they are major improvements. >>>>>>> For example, we now allow users to specify many input key/values and >>>>>>> have distributed cache support. For quick reference: >>>>>>> http://s.apache.org/NQY >>>>>>> >>>>>>> Brock >>>>>>> >>>>>>> >>>>>>> On Thu, Sep 13, 2012 at 8:16 AM, Jim Donofrio <donofrio...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Yes graduation has nothing to do with the quality or state of the >>>>>>>> code, >>>>>>>> graduation is all about community and should not influence a release >>>>>>>> number. >>>>>>>> >>>>>>>> I agree that 1.0 would signal a breaking change but 1.0 should also >>>>>>>> signal >>>>>>>> major improvements, api changes, new features. I dont think this >>>>>>>> release >>>>>>>> contains any drastic features. I think we should continue in the 0.* >>>>>>>> versions for awhile until we add major new features such as Tool >>>>>>>> support. At >>>>>>>> that time you can change the package names to org.apache.mrunit and >>>>>>>> go to >>>>>>>> 1.0. I would rather not become like Firefox or Chrome and do major >>>>>>>> release >>>>>>>> number changes on every release. >>>>>>>> >>>>>>>> >>>>>>>> On 09/13/2012 06:31 AM, Jarek Jarcec Cecho wrote: >>>>>>>>> >>>>>>>>> I do have similar reasoning here: >>>>>>>>> >>>>>>>>> 1.0 - in case that we're breaking backward compatibility >>>>>>>>> 0.10 - in case that we're not breaking backward compatibility >>>>>>>>> >>>>>>>>> I personally do not see graduation of the project important enough >>>>>>>>> for the >>>>>>>>> version to jump to next major. We've recently graduated sqoop and >>>>>>>>> flume and >>>>>>>>> remained on the same major version without any issues. >>>>>>>>> >>>>>>>>> But I'll support next reason no matter the final version. >>>>>>>>> >>>>>>>>> Jarcec >>>>>>>>> >>>>>>>>> On Wed, Sep 12, 2012 at 11:41:08PM +0200, Bertrand Dechoux wrote: >>>>>>>>>> >>>>>>>>>> And I would say the same in a reverse way. >>>>>>>>>> If we do a 1.0 release, all required incompatible changes should be >>>>>>>>>> done >>>>>>>>>> so >>>>>>>>>> that there would be no need to drag unneeded deprecated stuff from >>>>>>>>>> the >>>>>>>>>> 1.0 >>>>>>>>>> up to the 2.0. >>>>>>>>>> >>>>>>>>>> For me, the question is whether we should break compatibility for >>>>>>>>>> the >>>>>>>>>> next >>>>>>>>>> release. If yes, then break all which is necessary for a clean >>>>>>>>>> future. If >>>>>>>>>> not, then assure full compatibility. If yes, it should be 1.0. If >>>>>>>>>> not, it >>>>>>>>>> should be 0.10. >>>>>>>>>> >>>>>>>>>> The following question is then : if we keep compatibility what will >>>>>>>>>> the >>>>>>>>>> next release ship with? Is a release worth the new features/bug >>>>>>>>>> fixes? On >>>>>>>>>> that point, I am not knowledgeable enough to answer. I would accept >>>>>>>>>> the >>>>>>>>>> decisions of the more 'ancient' devs. But it should indeed be >>>>>>>>>> discussed. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Bertrand >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Sep 12, 2012 at 9:05 PM, Wei, Jianbin <jianb...@paypal.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> If it is an incompatible change in non-trivial way, I would strong >>>>>>>>>>> in >>>>>>>>>>> favor a 1.0 release. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> -- Jianbin >>>>>>>>>>> >>>>>>>>>>> On Sep 12, 2012, at 10:01 AM, Brock Noland wrote: >>>>>>>>>>> >>>>>>>>>>> OK, we have the following viewpoints with supporting reasons: >>>>>>>>>>> >>>>>>>>>>> 0.10 - supported by a number of people (reasons: none given, 1.0 >>>>>>>>>>> should be used for Tool interface support) >>>>>>>>>>> 1.0 - supported by a number of people (reasons: none given, recent >>>>>>>>>>> graduation, due to the incompatible change) >>>>>>>>>>> >>>>>>>>>>> I tilt towards the 1.0 release due to the incompatible changes but >>>>>>>>>>> I >>>>>>>>>>> am not strongly committed to that viewpoint. I am strongly >>>>>>>>>>> committed >>>>>>>>>>> to a release whatever the number! :) It would seem easy enough to >>>>>>>>>>> vote >>>>>>>>>>> on the matter but I think votes can become divisive. I have seen >>>>>>>>>>> that >>>>>>>>>>> in the Hadoop community when voting is used to resolve issues it >>>>>>>>>>> ends >>>>>>>>>>> up much like the state of US politics. As such, I'd prefer to >>>>>>>>>>> settle >>>>>>>>>>> this via discussion. >>>>>>>>>>> >>>>>>>>>>> We have all stated our preferences but not our convictions. Is >>>>>>>>>>> there >>>>>>>>>>> anyone who strongly in favor of / opposed to a 0.10 release? Is >>>>>>>>>>> there >>>>>>>>>>> anyone who is strongly in favor of / opposed to a 1.0 release? If >>>>>>>>>>> so >>>>>>>>>>> please state your reasoning. >>>>>>>>>>> >>>>>>>>>>> Brock >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 7, 2012 at 11:50 AM, Wei, Jianbin >>>>>>>>>>> <jianb...@paypal.com<mailto: >>>>>>>>>>> jianb...@paypal.com>> wrote: >>>>>>>>>>> Agree with Dave that when it becomes incompatible, the major >>>>>>>>>>> version >>>>>>>>>>> number should be increased. Major changes also warrant a major >>>>>>>>>>> number >>>>>>>>>>> change. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> -- Jianbin >>>>>>>>>>> >>>>>>>>>>> On Sep 7, 2012, at 8:06 AM, Brock Noland wrote: >>>>>>>>>>> >>>>>>>>>>> As I understand it, if we implement >>>>>>>>>>> https://issues.apache.org/jira/browse/MRUNIT-138 as described in >>>>>>>>>>> the >>>>>>>>>>> JIRA. That is, all the drivers keep state of the inputs, we can >>>>>>>>>>> undeprecate the methods depcrecated in >>>>>>>>>>> https://issues.apache.org/jira/browse/MRUNIT-64? >>>>>>>>>>> >>>>>>>>>>> Brock >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 7, 2012 at 7:58 AM, Jim Donofrio >>>>>>>>>>> <donofrio...@gmail.com >>>>>>>>>>> <mailto:donofrio...@gmail.com>> wrote: >>>>>>>>>>> I think we need to keep those deprecated methods around for >>>>>>>>>>> awhile, no >>>>>>>>>>> reason to anger users. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 09/07/2012 08:35 AM, Bertrand Dechoux wrote: >>>>>>>>>>> >>>>>>>>>>> Then the question is about when/if the compatibility should be >>>>>>>>>>> broken. >>>>>>>>>>> >>>>>>>>>>> https://issues.apache.org/jira/browse/MRUNIT-139 would be quite >>>>>>>>>>> easy >>>>>>>>>>> without the history of MRUnit and the @Deprecated.... >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 7, 2012 at 2:19 PM, Dave Beech >>>>>>>>>>> <d...@paraliatech.com<mailto: >>>>>>>>>>> d...@paraliatech.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> I think this depends on what we decide to do about MRUNIT-138. We >>>>>>>>>>> were >>>>>>>>>>> discussing an incompatible change, and if we do decide to do that >>>>>>>>>>> I >>>>>>>>>>> think >>>>>>>>>>> the version number should increase to 1.0.0 to reflect this (and >>>>>>>>>>> also >>>>>>>>>>> the >>>>>>>>>>> fact that this is the first version since graduation). >>>>>>>>>>> >>>>>>>>>>> If we later go ahead with the API rewrite (MRUNIT-69), this could >>>>>>>>>>> form >>>>>>>>>>> MRUnit 2.0.0! Would line up nicely with Hadoop's own numbering >>>>>>>>>>> strategy >>>>>>>>>>> ;) >>>>>>>>>>> >>>>>>>>>>> On 7 September 2012 07:54, James Kinley >>>>>>>>>>> <kin...@cloudera.com<mailto: >>>>>>>>>>> kin...@cloudera.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> +1 for the 1.0.0 release. I think it's a good idea to increase the >>>>>>>>>>> major >>>>>>>>>>> version number considering the recent graduation and the included >>>>>>>>>>> >>>>>>>>>>> changes. >>>>>>>>>>> >>>>>>>>>>> On 7 Sep 2012, at 07:29, "Wei, Jianbin" >>>>>>>>>>> <jianb...@paypal.com<mailto: >>>>>>>>>>> jianb...@paypal.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> My bad, 0.9.0 --> 0.10.0 is also version increase. My eyes are >>>>>>>>>>> not >>>>>>>>>>> >>>>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> to have a 2 digits minor version yet. However, I still prefer a >>>>>>>>>>> >>>>>>>>>>> one-digit >>>>>>>>>>> >>>>>>>>>>> minor version as most software do that in practice. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> -- Jianbin >>>>>>>>>>> >>>>>>>>>>> On Sep 6, 2012, at 10:41 PM, Bertrand Dechoux wrote: >>>>>>>>>>> >>>>>>>>>>> I am not sure to understand "It is not good to backtracking >>>>>>>>>>> version.". >>>>>>>>>>> Does it mean that the version after graduating should show the >>>>>>>>>>> 'step'? >>>>>>>>>>> Is that a common way to do it? >>>>>>>>>>> >>>>>>>>>>> Not taking into account the graduation, I would also favor the >>>>>>>>>>> "0.10.0" >>>>>>>>>>> instead of "1.0.0". >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Bertrand >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Apache MRUnit - Unit testing MapReduce - >>>>>>>>>>> http://incubator.apache.org/mrunit/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Apache MRUnit - Unit testing MapReduce - >>>>>>>>>>> http://incubator.apache.org/mrunit/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Bertrand Dechoux >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Apache MRUnit - Unit testing MapReduce - >>>>>>> http://incubator.apache.org/mrunit/ >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Apache MRUnit - Unit testing MapReduce - >>>>>> http://incubator.apache.org/mrunit/ >> >> > > > > -- > Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
