On Sun, Jul 27, 2014 at 9:28 PM, Ted Dunning tdunn...@maprtech.com wrote:
I don't know of any dev environments in common use today that can't display
100 characters.
I edit in an 80-column Emacs window that just fits beside an 80-column
shell window on a portrait-rotated 24 monitor.
Doug
On Fri, May 30, 2014 at 11:05 PM, Niels Basjes ni...@basjes.nl wrote:
How would someone create the situation you are referring to?
By renaming files. I believe I can easily write a test using public
APIs that will succeed without this patch and will fail with this
patch. Given the number of
will suddenly be different (which is the correct answer) and the
jobs will finish sooner because the input is not processed multiple times.
Where do you see a performance impact?
Niels
On May 30, 2014 8:06 PM, Doug Cutting cutt...@apache.org wrote:
On Thu, May 29, 2014 at 2:47 AM, Niels Basjes ni
On Wed, Jan 29, 2014 at 12:30 PM, Jason Lowe jl...@yahoo-inc.com wrote:
It is a bit concerning that the JIRA history showed that the target version
was set at some point in the past but no record of it being cleared.
Perhaps the version itself was renamed?
Doug
On Fri, Oct 25, 2013 at 9:35 AM, Suresh Srinivas sur...@hortonworks.com wrote:
Granted some of the feature readiness activity can be done during voting.
But I fail to understand why expediting a feature that takes months to build
should try to optimize a week. Why not finish the requirements we
On Fri, Oct 25, 2013 at 10:56 AM, Vinod Kumar Vavilapalli
vino...@apache.org wrote:
Discussing on a voting thread is not productive.
When all votes are +1 then no discussion is needed. One shouldn't
call a vote unless one expects all votes to be +1. But, if
unexpectedly they're not all +1,
On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth cnaur...@hortonworks.com wrote:
When the voting happens on jira with a finalized merge patch, I know
exactly what I'm voting for, because it's the same review-and-commit
process that we follow every day with the extra requirement of 3 +1s. When
http://www.apache.org/dev/version-control.html#https-svn-config
Doug
On Jun 28, 2013 1:03 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote:
Clarification: svn:eol-style = native causes the files to contain
whatever the native platform used to check out the code uses. I think
just setting this
On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy a...@hortonworks.com wrote:
To get past all of this confusion, I'd like to present an alternate, specific
proposal for consideration.
I propose we continue the original plan and make a 2.0.5-beta release by May
end with the following content:
On Wed, Dec 12, 2012 at 10:20 AM, Alejandro Abdelnur t...@cloudera.com wrote:
you can do mvn install in the plugins project and then you'll be able to
use it from the project you are using the plugin.
Avro has its Maven plugins in a module that's used when compiling
other modules. You can
On Mon, Dec 3, 2012 at 11:21 AM, Matt Foley mfo...@hortonworks.com wrote:
It is intended to be a technical discussion, in the sense of the bylaws
statement (in section Roles and Responsibilities: Committers), Committers
may cast binding votes on any technical discussion regarding any
languages for no reason.
--Matt
On Mon, Dec 3, 2012 at 3:57 PM, Doug Cutting cutt...@apache.org wrote:
On Mon, Dec 3, 2012 at 2:08 PM, Matt Foley mfo...@hortonworks.com wrote:
The apache voting process contradicts the Hadoop bylaws:
http://www.apache.org/foundation/voting.html says that only
-1, +1, -1
Run- build-time scripting should be limited to operations that are
impossible in Java. These should not be complex nor should we
encourage more complexity in them. A parallel set of simple .bat
files for such operations seems preferable to adding a Python
dependency.
Doug
On Sat,
The moderators of this list can be contacted at common-dev-owner at
hadoop.apache.org.
If you'd like to become a moderator, please send a message to apmail
at apache.org asking to become a moderator. CC private at
hadoop.apache.org to keep the PMC in the loop.
[
https://issues.apache.org/jira/browse/HADOOP-8662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-8662.
--
Resolution: Fixed
I committed this. The new site is now live.
Konstantin: I removed your
[
https://issues.apache.org/jira/browse/HADOOP-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-8752.
--
Resolution: Duplicate
Fix Version/s: site
Assignee: (was: Eli Collins
Doug Cutting created HADOOP-8662:
Summary: remove separate pages for Common, HDFS MR projects
Key: HADOOP-8662
URL: https://issues.apache.org/jira/browse/HADOOP-8662
Project: Hadoop Common
On Thu, Jul 26, 2012 at 7:42 AM, Robert Evans ev...@yahoo-inc.com wrote:
About the only time that
MultiThreaded mapper makes a lot of since is if there is a lot of
computation associated with each key/value pair.
Or if the mapper does a lot of i/o to some external resource, e.g., a
web
On 03/28/2012 12:39 PM, Owen O'Malley wrote:
[ ... ] So the RM of the 2 branch needs to make the call of what
should be 2.1 vs 3.0.
I thought these were community decisions, not RM decisions, no?
http://s.apache.org/rm
Doug
On 02/12/2012 10:02 PM, Roman Shaposhnik wrote:
For issues like these it always helps to file an INFRA Jira.
It's good to first check the ASF monitoring status page:
http://monitoring.apache.org/status/
If there's a red on that page then Infrastructure is already aware of
the problem.
Another
[
https://issues.apache.org/jira/browse/HADOOP-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting reopened HADOOP-7920:
--
There are a few more things that can be removed.
Remove Avro RPC
On 11/21/2011 11:49 AM, Matt Foley wrote:
The advantage of CHANGES.txt is that it merges when the branch merges. So
as long as the developers stick to reasonably normal merge and commit
processes, it truly reflects what is in the current state of any given
branch, at least at the level of
Components: ipc
Reporter: Doug Cutting
Assignee: Doug Cutting
HADOOP-7524 introduced a new way of passing protocols to RPC servers, but it
was not implemented correctly by AvroRpcEngine in that issue. This is required
to fix HDFS-2298.
--
This message is automatically
[
https://issues.apache.org/jira/browse/HADOOP-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-4905.
--
Resolution: Invalid
Resolving as 'Invalid' since these static initializers are no long
On 09/10/2011 01:32 AM, Vinod Kumar Vavilapalli wrote:
Regarding patch names, I too agree with Allen that extension should be .txt.
I do run into patches every now and then which aren't interpreted as text
files, so there are people out there using browsers that don't properly set
the
On 09/09/2011 07:27 AM, Ted Dunning wrote:
If you post the same patch with the same name, JIRA helps you out by greying
all the earlier versions out.
Indeed. That's the best practice, not to add version numbers to patch
files, for this very reason. We should perhaps note this on:
On 09/09/2011 11:12 AM, Eli Collins wrote:
Personally I like version numbers as well, it allows me to refer to a
specific version of the patch (vs a patch on a given time of
date/date).
Re-using the name doesn't hide the old versions, it just makes them
gray. They're still listed, with date
On 09/09/2011 01:38 PM, Kirby Bohling wrote:
Someday I wish Apache would find/adopt a distributed version control
system (I know about git.apache.org, but I mean pushing that further),
and use something like gerrit or review board. So if you have a
patch, or a series of patches, you'd just
[
https://issues.apache.org/jira/browse/HADOOP-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-7562.
--
Resolution: Fixed
Assignee: Doug Cutting
Hadoop Flags: [Reviewed]
Turns out
On 04/29/2011 04:09 PM, Owen O'Malley wrote:
I think everything is ready to go on the 0.20.203.0 release. It
includes security and a lot of improvements in the capacity scheduler
and JobTracker.
This does not appear to include the 0.20-append work? So it's not
advisable to use HBase with this
On 05/02/2011 11:37 AM, Alan Gates wrote:
From the viewpoint of a downstream user, I'd like to see this released.
Right now Hive 0.7 and soon HCatalog 0.1 have to depend on a Cloudera
distribution because they need security. Having Apache products depend
on 3rd party distributions of Apache
I edited the LocalBadContent page to prohibit linking to these domains.
Doug
On 01/10/2011 02:46 AM, Niels Basjes wrote:
Seems like a good moment to blacklist the prosch user from ever
changing the wiki again.
2011/1/10 Apache Wikiwikidi...@apache.org:
Dear Wiki user,
You have subscribed to
The problem was that the submitter could transition from Patch
Available to In Progress, following the Resume Progress transition,
but the submitter cannot then transtion anywhere from In Progress,
only the assignee could. I fixed that, so that the assignee can no
longer follow that
[
https://issues.apache.org/jira/browse/HADOOP-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-4617.
--
Resolution: Duplicate
Thanks for noticing this stale issue, Paul!
what about hdfs-default
Versions: site
Reporter: Doug Cutting
Fix For: site
We should agree on a Powered By Hadoop logo, as suggested in:
http://www.apache.org/foundation/marks/pmcs#poweredby
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment
Arun, are you still interested in this issue?
https://issues.apache.org/jira/browse/HADOOP-6317
This was the oldest item in the patch queue. I have updated the patch
to apply to current trunk. It looks like a reasonable feature to me.
You originally filed the issue. Aaron supplied a patch
[
https://issues.apache.org/jira/browse/HADOOP-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-6992.
--
Resolution: Fixed
Hadoop Flags: [Reviewed]
Hive has now moved its website, so I have
Does anyone know who SomeOtherAccount is? They've been making good
changes to the wiki. It'd be nice to know who this is, rather than
keeping it anonymous.
Thanks,
Doug
On 09/17/2010 09:59 AM, Apache Wiki wrote:
Dear wiki user,
You have subscribed to a wiki page Hadoop Wiki for change
Owen O'Malley wrote:
and hopefully to get the new generic serialization api in before the
branch.
Is this just HADOOP-6685? Or does it also include MAPREDUCE-1183?
My instinct would rather be to revert the serialization API changes made
since 0.20 (mostly HADOOP-6165) if that's not an API
Owen O'Malley wrote:
In my experience with releasing Hadoop, the bare minimum of scale
testing is a couple of weeks on 500 nodes (and more is far better) with
a team of people testing it. I think that releasing a 1.0 that has never
been tested at scale would be disastrous.
For the record, I
Chris Douglas wrote:
Speaking of the release vote process, I renew my request that we
formalize both the RM role and the bylaws. -C
I think the HTTPD release rules are non-controversial and would support
adoption of something similar. Someone needs to draft a proposal,
initiate a
Chris K Wensel wrote:
are we saying we will de-deprecate the stable APIs in .20, or make the new APIs
introduced in .20 stable?
+1 on removing the deprecations on the stable APIs.
Yes. I too am +1 on removing deprecations in stable, public APIs in a
1.0 release. Code that uses only public
Todd Lipcon wrote:
With HDFS-200 we'd also need HDFS-142
Good to know. I' have to admit to being puzzled by HDFS-200, since
Nicholas resolved it as a duplicate on 7 January, yet Dhruba's continued
to post patches to it.
Dhruba, Stack: do you have any thoughts on the appropriateness of
Owen O'Malley wrote:
It is tempting and I think that 0.20 is *really* our 1.0, but I think
re-labeling a release a year after it came out would be confusing.
I wasn't proposing just a re-labeling. I was proposing a new release,
branched from 0.20 rather than trunk. We'd introduce some
Konstantin Shvachko wrote:
I would like to propose a straightforward release of 0.21 from current
0.21 branch.
That could be done too. Tom's volunteered to drive a release from trunk
in a few weeks. Owen's volunteered to drive another release from trunk
in about six months. Would you like
[
https://issues.apache.org/jira/browse/HADOOP-6660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-6660.
--
Resolution: Duplicate
Fix Version/s: (was: 0.22.0)
add wrapper for Avro data
Tom White wrote:
I think the focus should be on getting an alpha release
out, so I suggest we create a new 0.21 branch from trunk
Another release we might consider is 1.0 based on 0.20. We'd then have
releases that correspond to what folks are actually using in production.
This would also
add Writable wrapper for Avro data
--
Key: HADOOP-6660
URL: https://issues.apache.org/jira/browse/HADOOP-6660
Project: Hadoop Common
Issue Type: New Feature
Components: io
Reporter: Doug
Switch RPC to use Avro
--
Key: HADOOP-6659
URL: https://issues.apache.org/jira/browse/HADOOP-6659
Project: Hadoop Common
Issue Type: Improvement
Components: ipc
Reporter: Doug Cutting
: Improvement
Components: build
Reporter: Doug Cutting
Currently the Maven POM file is generated from a template file that includes
the versions of all the libraries we depend on. The versions of these
libraries are also present in ivy/libraries.properties, so that, when a library
Owen O'Malley wrote:
Doug decided he didn't like the majority of people editing their comments on
jira and disabled edits.
I did propose that we disable comment editing. There was some
discussion, but no one vetoed the proposal, so I implemented it.
The rationale is that comment edits as
Components: ipc
Reporter: Doug Cutting
Assignee: Doug Cutting
Fix For: 0.22.0
A few minor changes are required to get some common classes to work correctly
with Avro 1.3 reflection.
--
This message is automatically generated by JIRA.
-
You can reply to this email
Reporter: Doug Cutting
Assignee: Doug Cutting
Fix For: 0.22.0
To more easily permit Hadoop to evolve to use Avro RPC, I propose to change RPC
to use different implementations for clients and servers based on the
configuration. This is not intended as an end
Aaron Kimball wrote:
First, I've been picked on by others for using this brace style:
if (foo) {
stmt;
} else {
otherstmt;
}
and have been told to drop the braces because they look ugly if stmt or
otherstmt are only one line.
In
Can another committer please review this issue?
https://issues.apache.org/jira/browse/HADOOP-6318
Thanks,
Doug
Upgrade to Avro 1.2.0
-
Key: HADOOP-6318
URL: https://issues.apache.org/jira/browse/HADOOP-6318
Project: Hadoop Common
Issue Type: Improvement
Components: io, ipc
Reporter: Doug Cutting
[
https://issues.apache.org/jira/browse/HADOOP-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-6267.
--
Resolution: Fixed
Fix Version/s: 0.21.0
I just committed this. Thanks, Todd!
build
Sanjay Radia wrote:
No. The 1.0 proposal was that it included both API and wire compatibility.
The proposal includes a lot of things, but it's so far just a proposal.
There's been no vote to formally define what 1.0 will mean. In every
discussion I've heard, from the very beginning of the
[
https://issues.apache.org/jira/browse/HADOOP-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved HADOOP-6190.
--
Resolution: Fixed
Assignee: Doug Cutting
Good idea. I created that link. Thanks
59 matches
Mail list logo
