hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <had...@holsman.net>
Subject Re: DISCUSSION: Cut a hadoop-0.20.0-append release from the tip of branch-0.20-append branch?
Date Thu, 23 Dec 2010 23:33:33 GMT
The release is one issue, but ongoing maintenance of it is another, which is the point roy
raised. 

It's a concern if we have a security issue, and who will patch it (and test it) going forward.


---
Ian Holsman - 703 879-3128

I saw the angel in the marble and carved until I set him free -- Michelangelo

On 24/12/2010, at 9:39 AM, Ryan Rawson <ryanobjc@gmail.com> wrote:

> How does stack volunteering his time to release an existing branch
> divert resources?
> 
> Without an ASF release of 0.20-append I will keep having to recommend
> an external vendor's release of Hadoop.
> 
> 
> On Thu, Dec 23, 2010 at 2:18 PM, Konstantin Shvachko
> <shv.hadoop@gmail.com> wrote:
>> I also think building 0.20-append will be a major distraction from moving
>> 0.22 forward with all the great new features, including the new append
>> implementation, sitting on the bench because we are delaying the release.
>> It seems to be beneficial for the entire community to focus on 0.22 rather
>> than chasing both birds.
>> 
>> I hear a concern that 0.22 will lack large scale testing as was the case
>> with 0.21.
>> I'd like to volunteer to put as many large scale resources, as I can grasp,
>> into stabilizing of 0.22. Under Nigel's management of course.
>> This should get us to production quality in 3-6 months rather than
>> "another 12-15". I also hope it can go even faster/better if others
>> could join the effort. I see > 100 companies claiming they are powered by
>> Apache Hadoop.
>> 
>> I also hope with this effort HBase will be able to start moving to the new
>> append implementation in the next 2-3 months, which in turn will help 0.22
>> HDFS
>> rather than divert resources from it as it would have be with 0.20-append.
>> 
>> Stack, will this plan will work for HBase survival?
>> 
>> One other thought. Apache Hadoop community is not in control of external
>> releases and distributions, but we should not fork our own releases by
>> introducing
>> competing apis. If we can keep the dev line relatively straight the external
>> releases
>> will follow.
>> 
>> Thanks,
>> --Konstantin
>> 
>> 
>> On Thu, Dec 23, 2010 at 11:40 AM, Ryan Rawson <ryanobjc@gmail.com> wrote:
>> 
>>> The append solution in 0.22 that you are referring to was supposed to
>>> be out 13-15 months ago.  Pardon if I look for solutions that deploy 4
>>> months ago (as the 0.20 append branch did).
>>> 
>>> Another 12-15 months of delay is not exactly helping HDFS either.
>>> 
>>> -ryan
>>> 
>>> On Thu, Dec 23, 2010 at 9:38 AM, Jakob Homan <jghoman@gmail.com> wrote:
>>>> It's difficult to support this proposal knowing how much time would be
>>>> spent preparing an official release, continuing to support it and
>>>> continuing to two support two separate implementations of append.  I
>>>> believe that effort would be better spent getting out a kick-ass 22
>>>> (or, barring that, a *really* kick-ass 23).
>>>> 
>>>> The Promised Land that we say we're all trying to get to is regular,
>>>> timely, feature-complete, tested, innovative but stable releases of
>>>> new versions of Apache Hadoop.  Missing out any one of those criteria
>>>> discovered will continue (and has continued) the current situation
>>>> where quasi-official branches and outside distributions fill the void
>>>> such a release should.  The effort to maintain this offical branch and
>>>> fix the bugs that will be discovered could be better spent moving us
>>>> closer to that goal.
>>>> 
>>>> I'm certainly sympathetic to the difficult position our quagmire has
>>>> placed HBase into.  However, the current proposal would hurt HDFS to
>>>> help HBase. The best solution for that project, as well as for HDFS,
>>>> is to get HDFS back to a healthy release cycle; not prolong or codify
>>>> the current ad-hoc state of affairs.  Let's stop digging this hole.
>>>> -jakob
>>>> 
>>>> On Thu, Dec 23, 2010 at 9:33 AM, M. C. Srivas <mcsrivas@gmail.com>
>>> wrote:
>>>>> [ Sorry if this is be-laboring the obvious ]
>>>>> 
>>>>> There are two append solutions floating around, and they are
>>> incompatible
>>>>> with each other. Thus, the two "branches" will forever remain
>>> incompatible
>>>>> with each other, regardless of how they are numbered (0.22,  0.23,
>>>  0.20.3,
>>>>> e.t.c.)
>>>>> 
>>>>> Unless both are merged into one branch, and a switch provided to  "use
>>>>> HDFS-200 append" or "use 0.22 append", we have effectively split Hadoop
>>> into
>>>>> two.
>>>>> 
>>>>> 
>>>>> On Thu, Dec 23, 2010 at 12:00 AM, Owen O'Malley <omalley@apache.org>
>>> wrote:
>>>>> 
>>>>>> On Wed, Dec 22, 2010 at 11:07 PM, Roy T. Fielding <fielding@gbiv.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Features are not release version tags.  If there is a security
bug
>>>>>>> found then we would have to release a new version of the append
>>>>>>> version, and a round of severe trout slapping would result.
>>>>>>> 
>>>>>> 
>>>>>> Yeah, it isn't a perfect solution and it doesn't scale to a second
tag,
>>> but
>>>>>> the problem is that this is effectively a release branch between
0.20
>>> and
>>>>>> 0.21. Of course I agree that any critical bugs would need to be fixed
>>> in
>>>>>> the
>>>>>> append branch as well as the 0.20 and 0.21 branches.
>>>>>> 
>>>>>> If you want to stick to pure numbers and we want to leave ourselves
a
>>> way
>>>>>> to
>>>>>> bugfix the 0.20 branch without append, we'd could use a version string
>>> like
>>>>>> 0.20.100, etc. Not pretty, but it does preserve the numeric ordering
>>> and
>>>>>> suggest a version jump.
>>>>>> 
>>>>>> If I remember right, there were also protocol changes in the append
>>> branch,
>>>>>> which was another reason we didn't want to put it directly into the
>>> 0.20
>>>>>> branch.
>>>>>> 
>>>>>> -- Owen
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Mime
View raw message