hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: [VOTE] Release candidate 0.20.203.0-rc1
Date Thu, 05 May 2011 00:39:28 GMT
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