The instructions also mention "incubator" quite heavily. I'd be happy to do the release (but only if the instructions get fixed first!!)
On 26 September 2012 16:39, Brock Noland <br...@cloudera.com> wrote: > I suppose this will be the first release using git so the instructions > will have to be updated... > > On Wed, Sep 26, 2012 at 10:37 AM, Brock Noland <br...@cloudera.com> wrote: >> Hi, >> >> It's not a ton of work once you have done it, but the first time it >> can take some time. >> >> 1) Making sure we have the changes we said we would have in this release >> a) This release was contingent on a JIRA >> b) Ensuring the FIXED IN field in JIRA is correct >> 2) Executing the instructions here >> http://mrunit.apache.org/pmc/how_to_release.html >> >> Since we are a smaller project #1 is pretty easy. For projects like >> Hadoop #1 is a huge undertaking. For us, the real work is setting up >> your GPG keys and getting maven to deploy the jars correctly. >> Everything outside of environmental conditions *should* be documented >> in the release page. >> >> Since we are doing an incompatible change, we want to make sure the >> release notes reflect this. We also typically write a blog article >> (https://blogs.apache.org/mrunit/) and then ask Cloudera to re-post. >> In the past this has been about publicity for the project but this >> time it's probably a little more important due to the incompatibility. >> >> Brock >> >> On Wed, Sep 26, 2012 at 10:20 AM, Dave Beech <d...@paraliatech.com> wrote: >>> 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/ >> >> >> >> -- >> Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/ > > > > -- > Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
