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 >>>> 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 >
