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