Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


+
Matt Foley 2011-11-05, 00:56
+
Tim Broberg 2011-11-05, 06:42
+
Matt Foley 2011-11-10, 02:36
+
Nathan Roberts 2011-11-11, 21:41
+
Todd Lipcon 2011-11-11, 22:27
+
Eli Collins 2011-11-11, 00:32
+
Dhruba Borthakur 2011-11-11, 05:44
+
Suresh Srinivas 2011-11-11, 05:58
+
Todd Lipcon 2011-11-11, 06:24
+
Suresh Srinivas 2011-11-11, 06:41
+
Eli Collins 2011-11-11, 06:31
+
Matt Foley 2011-11-11, 09:29
+
Eli Collins 2011-11-11, 18:34
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:
+
Todd Lipcon 2011-11-11, 22:29
+
Andrew Purtell 2011-11-11, 23:08
+
Todd Lipcon 2011-11-14, 21:44
+
Jitendra Pandey 2011-11-23, 19:10
+
Suresh Srinivas 2011-11-23, 19:14
+
Matt Foley 2011-11-23, 22:56
+
Eli Collins 2011-11-23, 23:05
+
Matt Foley 2011-11-24, 01:20
+
Roman Shaposhnik 2011-11-24, 01:14
+
Matt Foley 2011-11-24, 01:33
+
Arun Murthy 2011-11-24, 01:35
+
Arun C Murthy 2011-11-24, 01:40
+
Roman Shaposhnik 2011-11-24, 01:44
+
Matt Foley 2011-11-08, 02:11
+
Matt Foley 2011-11-24, 01:29
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB