I agree that "destructive" is not the correct word to describe features
like snapshots and windows support. However, I also agree with Konstantin
that any large feature will have a destabilizing effect on the code base,
even if it is done on a branch and thoroughly tested before being merged
in. H
Hi Arun and Suresh,
I am glad my choice of words attracted your attention. I consider this
important for the project otherwise I wouldn't waste everybody's time.
You tend reacting on a latest message taken out of context, which does not
reveal full picture.
I'll try here to summarize my proposal a
On Thu, May 2, 2013 at 2:11 AM, Konstantin Shvachko
wrote:
> On Thu, May 2, 2013 at 12:07 AM, Chris Douglas wrote:
>> Can anyone remember why we vote on release plans? -C
>
> To vote on features to include in the release.
Since most features are developed in branches (requiring a merge
vote), ea
Konstantin,
On May 2, 2013, at 2:08 AM, Konstantin Shvachko wrote:
> I am arguing against invasive and destructive features proposed for the
> release.
> Just to remind here they are again, since the history has been wiped out.
>
> # Snapshots
> # NFS gateway for HDFS
> # HDFS-347 unix domain so
On Thu, May 2, 2013 at 12:07 AM, Chris Douglas wrote:
> Can anyone remember why we vote on release plans? -C
To vote on features to include in the release.
Thanks,
--Konstantin
I am not sure what was your point here. You seem to be assuming things I
never mentioned.
I am arguing against invasive and destructive features proposed for the
release.
Just to remind here they are again, since the history has been wiped out.
# Snapshots
# NFS gateway for HDFS
# HDFS-347 unix d
On Wed, May 1, 2013 at 6:24 PM, Arun C Murthy wrote:
> Having a strict policy leads to all sorts of further dialogues and issues we
> could do well without.
+1
Can anyone remember why we vote on release plans? -C
On May 1, 2013, at 4:08 PM, Konstantin Shvachko wrote:
> On Wed, May 1, 2013 at 1:15 PM, Arun C Murthy wrote:
>>
>> On Apr 30, 2013, at 4:28 PM, Konstantin Shvachko wrote:
>>
>>> If the next release has to be 2.0.5 I would like to make an alternative
>>> proposal, which would include
>>> - sta
On Wed, May 1, 2013 at 1:15 PM, Arun C Murthy wrote:
>
> On Apr 30, 2013, at 4:28 PM, Konstantin Shvachko wrote:
>
> > If the next release has to be 2.0.5 I would like to make an alternative
> > proposal, which would include
> > - stabilization of current 2.0.4
> > - making all API changes to allo
Konstantin,
On Apr 30, 2013, at 4:28 PM, Konstantin Shvachko wrote:
> Hi Arun,
>
> I am agnostic about version numbers too, as long as the count goes up.
> The discussion you are referring to is somewhat outdated, it was talking
> about 2.0.4-beta, which we already passed.
It's very relevant a
If there are no objections, I'll start a vote on this proposal now.
Thanks,
--Konstantin
On Tue, Apr 30, 2013 at 4:28 PM, Konstantin Shvachko
wrote:
> Hi Arun,
>
> I am agnostic about version numbers too, as long as the count goes up.
> The discussion you are referring to is somewhat outdated,
Hi Arun,
I am agnostic about version numbers too, as long as the count goes up.
The discussion you are referring to is somewhat outdated, it was talking
about 2.0.4-beta, which we already passed. It is talking about producing a
series "not suitable for general consumption", which isn't correct for
Agreed Luke. Thanks for pointing it out, I'll track it as such.
Arun
On Apr 26, 2013, at 1:37 PM, Luke Lu wrote:
> If protocol compatibility of v2 and v3 is a goal, HADOOP-8990 should be a
> blocker for v2.
>
> __Luke
>
> On Fri, Apr 26, 2013 at 12:07 PM, Eli Collins wrote:
>
>> On Fri, Apr
On Apr 26, 2013, at 12:07 PM, Eli Collins wrote:
> Arun, Suresh,
>
> Mind reviewing the following page Karthik put together on
> compatibility? http://wiki.apache.org/hadoop/Compatibility
Sure. Will do.
I just opened https://issues.apache.org/jira/browse/HADOOP-9517 to ensure we
capture it
Konstantin,
On Apr 26, 2013, at 4:34 PM, Konstantin Shvachko wrote:
> Do you think we can call the version you proposed to release
> 2.1.0 or 2.1.0-beta?
>
> The proposed new features imho do not exactly conform with the idea
> of dot-dot release, but definitely qualify for a major number change
On Thu, Apr 25, 2013 at 6:36 PM, Suresh Srinivas wrote:
> Thanks for starting this discussion. I volunteer to do a final review of
> protocol changes, so we can avoid incompatible changes to API and wire
> protocol post 2.0.5 in Common and HDFS.
>
> We have been working really hard on the followi
Arun, Suresh,
Very exciting to hear about this final push to stable Hadoop 2.
But I have a problem. Either with the plan or with the version number.
I'll be arguing for the number change below rather than the plan.
1. Based on features listed by Suresh it looks that you plan a heavy
feature-full
Arun,
Could you please define the release plan and put it into vote.
In accordance with the ByLaws. After this discussion of course.
http://hadoop.apache.org/bylaws.html
Release Plan
Defines the timetable and actions for a release. The plan also nominates a
Release Manager.
Lazy majority of activ
On Fri, Apr 26, 2013 at 2:42 PM, Suresh Srinivas wrote:
> Eli, I will post a more detailed reply soon. But one small correction:
>
>
> I'm also not sure there's currently consensus on what an incompatible
>> change is. For example, I think HADOOP-9151 is incompatible because it
>> broke client/ser
Eli, I will post a more detailed reply soon. But one small correction:
I'm also not sure there's currently consensus on what an incompatible
> change is. For example, I think HADOOP-9151 is incompatible because it
> broke client/server wire compatibility with previous releases and any
> change th
If protocol compatibility of v2 and v3 is a goal, HADOOP-8990 should be a
blocker for v2.
__Luke
On Fri, Apr 26, 2013 at 12:07 PM, Eli Collins wrote:
> On Fri, Apr 26, 2013 at 11:15 AM, Arun C Murthy
> wrote:
> >
> > On Apr 25, 2013, at 7:31 PM, Roman Shaposhnik wrote:
> >
> >> On Thu, Apr 25,
On Fri, Apr 26, 2013 at 11:15 AM, Arun C Murthy wrote:
>
> On Apr 25, 2013, at 7:31 PM, Roman Shaposhnik wrote:
>
>> On Thu, Apr 25, 2013 at 6:34 PM, Arun C Murthy wrote:
>>
>>> With that in mind, I really want to make a serious push to lock down APIs
>>> and wire-protocols for hadoop-2.0.5-beta
On Apr 25, 2013, at 7:31 PM, Roman Shaposhnik wrote:
> On Thu, Apr 25, 2013 at 6:34 PM, Arun C Murthy wrote:
>
>> With that in mind, I really want to make a serious push to lock down APIs
>> and wire-protocols for hadoop-2.0.5-beta.
>> Thus, we can confidently support hadoop-2.x in a compatibl
On Apr 25, 2013, at 6:36 PM, Suresh Srinivas wrote:
>> On Thu, Apr 25, 2013 at 6:34 PM, Arun C Murthy wrote:
>>
>> Similarly on HDFS side, can someone please help out by tagging features,
>> bug-fixes, protocol/API changes etc.? This way we can ensure HDFS APIs &
>> protocols are locked down to
Thanks for starting this discussion. I volunteer to do a final review of
protocol changes, so we can avoid incompatible changes to API and wire
protocol post 2.0.5 in Common and HDFS.
We have been working really hard on the following features. I would like to
get into 2.x and see it reach HDFS use
25 matches
Mail list logo
