hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <t...@cloudera.com>
Subject Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.
Date Fri, 11 Nov 2011 18:39:08 GMT
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 <eli@cloudera.com> 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 <mfoley@hortonworks.com> 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 <eli@cloudera.com> 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 <suresh@hortonworks.com>
>>> 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 <eli@cloudera.com> 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 <mattf@apache.org>
wrote:
>>> >> > Hi all,
>>> >> > I propose to make a 0.20.205.1 candidate soon, with the following
>>> sets of
>>> >> > patches:
>>> >> >
>>> >> >   - deficiencies in HBase support, pointed out by the HBase team
and
>>> >> others
>>> >> >   - deficiencies in webhdfs support on secure clusters
>>> >> >   - a couple last-minute fixes submitted to branch-0.20-security-205
>>> that
>>> >> >   were too late to be included in 205.0
>>> >> >
>>> >> > If you would like other patches included, and you feel it is
>>> appropriate
>>> >> to
>>> >> > have them in 205.1 rather than waiting for 206.0, please declare
them
>>> by
>>> >> > setting the "Target Versions" field in their Jiras, and they will
>>> receive
>>> >> > due consideration, assuming that the proposed patch is actually
>>> >> > contributed, tested, reviewed, approved, and committed
>>> >> > to branch-0.20-security-205 by the freeze date :-)
>>> >> >
>>> >> > I would like to make the rc0 candidate next Friday, so I propose
to
>>> >> declare
>>> >> > 205.1 code freeze at noon, PST, Friday 11 Nov.  If this is a problem
>>> for
>>> >> > anyone, please let me know.
>>> >> >
>>> >> > Thank you, and best regards,
>>> >> > --Matt (Release Manager)
>>> >> >
>>> >>
>>> >
>>>
>>
>

Mime
View raw message