I will have the release instructions updated tomorrow and then Dave is spinning the RC so it would be on his timeline.
On Thu, Sep 27, 2012 at 9:01 AM, Jim Donofrio <donofrio...@gmail.com> wrote: > When did you hope to cut a release candidate? > > We also need to go through the open tickets to see what can wait, Brock has > MRUNIT-136 as a blocker. Sorry for not contributing in awhile but I need to > fix some javadoc for 101,114,115. It would also be nice if someone did 111 > for this release because we really should be using the release plugin, makes > the whole process a lot easier. > > > On 09/26/2012 11:45 AM, Brock Noland wrote: >> >> OK that seems like a bargain! :) I'll work on updating the >> instructions to what I think they should be (based on the experience >> of the last few releases). >> >> Thanks! >> Brock >> >> On Wed, Sep 26, 2012 at 10:42 AM, Dave Beech <d...@paraliatech.com> wrote: >>> >>> 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/ >> >> >> > -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
