Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.


Copy link to this message
-
Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.
As a heads up, this will require some tweaks in downstream projects.
For example:

  https://issues.apache.org/jira/browse/HIVE-2570

Currently I cannot use Hive with Hadoop 0.20.20#.0 because of this.

Thanks.

Alejandro

On Fri, Nov 11, 2011 at 10:34 AM, Eli Collins <[EMAIL PROTECTED]> wrote:
> Hey Matt,
>
> My understanding of introducing the new 4 part version scheme was to
> provide stability. Eg if someone is running 0.20.205.0 wants to be
> able to get just critical bug fixes (maybe they don't even use HBase)
> to what they're running then they can use 205.1, .2 etc. If someone
> running 205 wants something that's more than a critical bug fix (eg a
> performance optimization like HDFS-2246) then they upgrade to the next
> minor version (206), which still supports a path for people running
> 205. This allows us to serve both users (those who want just critical
> bug fixes to what they're running and those who want stuff like perf
> improvements for HBase), while the plan of putting everything in the
> point release serves one type of user at the expense of the other.
> What's the disadvantage of putting this in 206? That can be released
> soon as well right? According to the wiki it was supposed to branch
> last month.
>
> Thanks,
> Eli
>
> On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley <[EMAIL PROTECTED]> wrote:
>> Hi Eli,
>> The reason I am looking at HDFS-2246 for 205 is that I and a number of
>> Hadoop and HBase community members really want 205 to have good support for
>> HBase.  This performance improvement turns out to be pretty important in
>> order to actually have good support for HBase.  In that sense, I'm inclined
>> to consider it a critical fix.
>>
>> However, I think you have a very valid point about trunk support.  Suresh,
>> can we have a concurrent submission to trunk?
>>
>> Also, I believe in the HDFS-2246 Jira, Todd requested extra time to review,
>> due to commitments at Hadoop World.  Todd, would Monday be sufficient extra
>> time, so as not to slow down the anticipated release schedule too much?
>>
>> Thanks, and regards,
>> --Matt
>>
>>
>> On Thu, Nov 10, 2011 at 10:31 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
>>
>>> Hey guys,
>>>
>>> HDFS-2246 is not a fix, it's a non-trivial performance optimization.
>>> The roadmap page is pretty clear..  "Point releases are made to fix
>>> critical bugs. They do not introduce new features or make other
>>> improvements other than fixing bugs".
>>>
>>> I'm not opposed to the change, I'm just pointing out that we agreed to
>>> develop trunk first, and we agreed to follow the release policies for
>>> the sustaining branch. I don't see why we can't honor those
>>> agreements, ie why not post a patch for trunk first and then backport
>>> it to 206? Reasonable?
>>>
>>> Thanks,
>>> Eli
>>>
>>> On Thu, Nov 10, 2011 at 9:58 PM, Suresh Srinivas <[EMAIL PROTECTED]>
>>> wrote:
>>> > Eli,
>>> >
>>> > As Jitendra indicated in the jira, this was originally supposed to be
>>> part
>>> > of 0.205. Due to time crunc, we could not get this done in 0.205. This
>>> can
>>> > be turned off by a flag and only can be enabled by users who want to use
>>> > the functionality. Given that, I feel it is okay to go into 0.205.1.
>>> >
>>> > I agree it would be good to have a trunk patch for this and make it part
>>> of
>>> > 0.23.
>>> >
>>> > Regards,
>>> > Suresh
>>> >
>>> > On Thu, Nov 10, 2011 at 4:32 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
>>> >
>>> >> Hey Matt,
>>> >>
>>> >> Is HDFS-2246 slated for 0.20.205.1?  Given that it's not a bug and is
>>> >> non-trivial it seems better suited for 206 than a point release. Also,
>>> >> per the sustaining roadmap - http://wiki.apache.org/hadoop/Roadmap -
>>> >> "Only functionality already committed to trunk should be submitted to
>>> >> a sustaining release." and this functionality does not yet have a
>>> >> patch for trunk yet (let alone committed).
>>> >>
>>> >> Thanks,
>>> >> Eli
>>> >>
>>> >> On Fri, Nov 4, 2011 at 5:56 PM, Matt Foley <[EMAIL PROTECTED]> wrote: