hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: [VOTE] Release candidate
Date Thu, 05 May 2011 00:43:44 GMT
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

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.


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>
>>>>>> 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.
>>>>>>> are
>>>>>>> false positives.
>>>>>> Also,  can you please provide a list on features which are not related
>>>>>> 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
>>>>> 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,
>>>>> 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
>>>>> due to inclusion of MAPREDUCE-2378, the trunk version of which is still
>>>>> 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
>>>>> committed.
>>>>> - MAPREDUCE-1904, committed without JIRA as:
>>>>> "        . Reducing new Path(), RawFileStatus() creation overhead
>>>>> 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,
>>>>> 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
>>>>> 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
>>>>> the last couple months of 203.
>>>>> -Todd
>>>>> --
>>>>> Todd Lipcon
>>>>> Software Engineer, Cloudera
>> --
>> thanks
>> mahadev
>> @mahadevkonar

View raw message