Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> Re: [VOTE] Release candidate

Copy link to this message
Re: [VOTE] Release candidate
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>> <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote:
>>>>> On Wed, May 4, 2011 at 4:11 PM, Arun C Murthy <[EMAIL PROTECTED]> 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