hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Baldeschwieler <eri...@yahoo-inc.com>
Subject Re: [VOTE] Release candidate 0.20.203.0-rc1
Date Thu, 05 May 2011 01:18:24 GMT
Ok. I'll bite.

The point of a vote is to learn what everyone thinks. So far we have learned:

1 - the team that is trying to contribute code and do a release thinks it is ready. 

2 - Cloudera does not think the release is a good idea. 

No more talk between the Team contributing code and cloudera will educate us further  Let's
hear from the rest of the community. 

In parallel on other threads, let's work out how to address concerns. That will be useful
however the vote goes. I promise to continue to work with everyone to help drive releases.


We've called a vote, so let it proceed. That is how apache works. 

Thanks!

---
E14 - typing on glass

PS this is my last comment on this thread. Start new ones if you are not casting a vote. 

On May 4, 2011, at 5:45 PM, "Konstantin Boudnik" <cos@apache.org> wrote:

> I tend to agree. Changing release model of Apache Hadoop train isn't
> something that should be done in a hassle or as a part of release
> voting.
> 
> If these questions aren't addressed - let's postpone the vote and
> discuss all the complications or implications until they sorted out or
> the consensus/compromise is reached.
> 
> Cos
> 
> On Wed, May 4, 2011 at 17:39, Eli Collins <eli@cloudera.com> wrote:
>> The point is that these discussion should be sorted out, ie you don't
>> change your development and release model on a release VOTE thread,
>> you change it on a DISCUSSION thread.
>> 
>> Ie before we release this we should understand what that means. What
>> is being proposed is not just another release from branch-0.20 or
>> branch-0.22.
>> 
>> Thanks,
>> Eli
>> 
>> On Wed, May 4, 2011 at 5:30 PM, Mahadev Konar <mahadev@apache.org> wrote:
>>> Eli,
>>>  I think the intent from the email was to just vote on this thread,
>>> which I agree with.
>>>  Discussions should be done in a separate threads. Hopefully we can
>>> all stick to just voting!
>>> 
>>> thanks
>>> mahadev
>>> 
>>> On Wed, May 4, 2011 at 5:22 PM, Eli Collins <eli@cloudera.com> wrote:
>>>> Good suggestion, it would be helpful to hash out the issues around
>>>> compatibility, feature branches, version numbers, how to contribute at
>>>> Apache before putting up new votes that would be helpful, ie the vote
>>>> would go much smoother if all the issues with the previous vote were
>>>> addressed before starting a new one.
>>>> 
>>>> Thanks,
>>>> Eli
>>>> 
>>>> On Wed, May 4, 2011 at 5:05 PM, Eric Baldeschwieler
>>>> <eric14@yahoo-inc.com> wrote:
>>>>> Hi folks,
>>>>> 
>>>>> Let's stay focused. Let's take the other threads onto other threads.
This is a vote.
>>>>> 
>>>>> To the extent naming is a problem, let's take that to a thread and find
an acceptable proposal.
>>>>> 
>>>>> To the extent folks want to collaborate on certifying the release for
total lack of regression or collaborate on the cleanest possible merge, I think all interested
parties should take these topics to another thread and divide up the work.
>>>>> 
>>>>> If you've voted, you don't need to comment further on this thread, no
matter what company you work for!
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> ---
>>>>> E14 - typing on glass
>>>>> 
>>>>> On May 4, 2011, at 4:46 PM, "Todd Lipcon" <todd@cloudera.com> wrote:
>>>>> 
>>>>>> On Wed, May 4, 2011 at 4:11 PM, Arun C Murthy <acm@yahoo-inc.com>
wrote:
>>>>>> 
>>>>>>> On May 4, 2011, at 4:09 PM, Tsz Wo (Nicholas), Sze wrote:
>>>>>>> 
>>>>>>> The list seems highly inaccurate.  Checked the first few N/A
items.  All
>>>>>>>> are
>>>>>>>> false positives.
>>>>>>>> 
>>>>>>>> 
>>>>>>> Also,  can you please provide a list on features which are not
related to
>>>>>>> gridmix benchmarks or herriot tests?
>>>>>>> 
>>>>>> 
>>>>>> Here are a few I quickly pulled up:
>>>>>> MAPREDUCE-2316 (docs for improved capacity scheduler)
>>>>>> MAPREDUCE-2355 (adds new config for heartbeat dampening in MR)
>>>>>> 
>>>>>> "   BZ-4182948. Add statistics logging to Fred for better visibility
into
>>>>>> startup time costs. (Matt Foley)"
>>>>>> - I believe I saw a note from Matt on the JIRA yesterday about this
feature,
>>>>>> where he decided that the version done in 203 wasn't a good approach,
and
>>>>>> it's done differently in trunk (not sure if done yet).
>>>>>> 
>>>>>> MAPREDUCE-2364 (important bug fix for localization)
>>>>>> - in fact most of localization is different in this branch compared
to trunk
>>>>>> due to inclusion of MAPREDUCE-2378, the trunk version of which is
still on
>>>>>> the "yahoo-merge" branch,.
>>>>>> 
>>>>>> "New cunters for FileInput/OutputFormat. New Counter
>>>>>>        MAP_OUTPUT_MATERIALZIED_BYTES. Related bugs: 4241034, 3418543,
>>>>>> 4217546"
>>>>>> - not sure which JIRA this is, I think I've seen a JIRA for trunk,
but not
>>>>>> committed.
>>>>>> 
>>>>>> - MAPREDUCE-1904, committed without JIRA as:
>>>>>> "        . Reducing new Path(), RawFileStatus() creation overhead
in
>>>>>> LocalDirAllocator"
>>>>>> not in trunk
>>>>>> 
>>>>>> +    BZ4101537 .  When a queue is built without any access rights
we explain
>>>>>> the
>>>>>> +    problem.  (dking, rvw ramach)  [attachment of 2010-11-24]
>>>>>> seems to be on trunk as MR-2411, but not committed, best I can tell,
despite
>>>>>> the JIRA there being resolved (based on looking at QueueManager in
trunk)
>>>>>> 
>>>>>> "        . Remove unnecessary reference to user configuration from
>>>>>> TaskDistributedCacheManager causing memory leaks"
>>>>>> Not in trunk, not sure which JIRA it might be.. probably part of
2178.
>>>>>> 
>>>>>> Major new feature: MAPREDUCE-323 - very large rework of how job history
>>>>>> files are managed
>>>>>> Major change: MAPREDUCE-1100/MAPREDUCE-1176: unresolved on trunk,
though
>>>>>> probably will be attacked by different JIRAs
>>>>>> Major new ops-visible feature: "metrics2" system
>>>>>> Major new ops-visible feature: MAPREDUCE-291 job history can be viewed
from
>>>>>> a separate server
>>>>>> Major new set of user-visible configurations: MAPREDUCE-1943 and
friends
>>>>>> which implement new limits in MapReduce (eg MAPREDUCE-1872 as well)
>>>>>> 
>>>>>> I have code to work on, so I won't keep going, but this is from looking
at
>>>>>> the last couple months of 203.
>>>>>> 
>>>>>> -Todd
>>>>>> --
>>>>>> Todd Lipcon
>>>>>> Software Engineer, Cloudera
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> thanks
>>> mahadev
>>> @mahadevkonar
>>> 
>> 

Mime
View raw message