On Sun, Jul 27, 2014 at 9:28 PM, Ted Dunning 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 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 Hadoop-based appl
a common non splittable compression (like gzip) then the
> output 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, 20
On Thu, May 29, 2014 at 2:47 AM, Niels Basjes wrote:
> For arguments I still do not fully understand this was rejected by Todd and
> Doug.
Performance is a part of compatibility.
Doug
On Wed, Jan 29, 2014 at 12:30 PM, Jason Lowe 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 10:56 AM, Vinod Kumar Vavilapalli
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, then a discussion mus
On Fri, Oct 25, 2013 at 9:35 AM, Suresh Srinivas 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 have for
> every pa
On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth 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
> it happens on email, i
On Fri, Aug 9, 2013 at 1:15 PM, Alejandro Abdelnur wrote:
> pinging again, I need help from somebody with sudo access to the hadoop
> jenkins boxes to do this or to get sudo access for a couple of hours to set
> up myself.
Have you asked on builds@ or filed an INFRA Jira issue or asked on #asfinf
http://www.apache.org/dev/version-control.html#https-svn-config
Doug
On Jun 28, 2013 1:03 PM, "Colin McCabe" 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 property on all the
On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy 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:
If you intend t
On Wed, Dec 12, 2012 at 10:20 AM, Alejandro Abdelnur 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 build all of Avro wi
On Wed, Dec 5, 2012 at 9:24 AM, Alejandro Abdelnur wrote:
> Current tasks of the build for being 'pluginized' are:
>
> 1* cmake (HADOOP-8887)
> 2* protoc(HADOOP-9117)
> 3* saveVersion (HADOOP-8924) (but this one has been -1)
> [ ... ]
> While we could argue this plugins are general purpose and the
platform-independent solution, or force contributors to maintain parallel
> scripts in multiple platform-specific languages for no reason.
>
> --Matt
>
>
> On Mon, Dec 3, 2012 at 3:57 PM, Doug Cutting wrote:
>
>> On Mon, Dec 3, 2012 at 2:08 PM, Matt Foley wrote:
>
On Mon, Dec 3, 2012 at 2:08 PM, Matt Foley wrote:
> The apache voting process contradicts the Hadoop bylaws:
> http://www.apache.org/foundation/voting.html says that only PMC members can
> make binding votes on code modification issues, but
> http://hadoop.apache.org/bylaws.html says that Committe
On Mon, Dec 3, 2012 at 11:21 AM, Matt Foley 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
> subproject." I therefo
On Sat, Nov 24, 2012 at 12:13 PM, Matt Foley wrote:
> Vote closes at 12:30pm PST on Saturday 1 December.
It's not clear to me what kind of a vote this is. It seems closest to
a code change vote, since it implies code changes, although without a
specific patch yet proposed. As such it would foll
On Sat, Dec 1, 2012 at 2:44 AM, Steve Loughran wrote:
> WinNT Bat/CMD files are the worst possible scripting language invented. At
> the very least, .py should be the language of choice there
The scripts should not have so much logic that .bat files are a problem.
Doug
-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.
http://www.apache.org/dev/committer
[
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
[
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
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 Co
On Thu, Jul 26, 2012 at 7:42 AM, Robert Evans 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 crawler.
Doug
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
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 a
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 conte
On 09/09/2011 02:15 PM, Kirby Bohling wrote:
> Fair enough Doug. Somebody else will have to do that, I don't have
> commit access (a pre-requisite for access to the private lists). I'd
> make the suggestion there, but I literally can't.
Such suggestions have been made before. What's lacking are
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
On 09/09/2011 01:08 PM, Allen Wittenauer wrote:
> s,patch,txt, since jira doesn't appear to pass a content-type to indicate it
> is readable by the browser (as you mentioned earlier).
I think Jira uses the content-type that the browser posts with. My
browser (Chrome on Ubuntu) posts .patch files
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 dat
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:
http://wik
[
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 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 Apac
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 th
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 Wiki:
Dear Wiki user,
You have subscribed to a wiki page or wiki
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 tr
Alex,
Generally when someone contributes a patch and a committer reviews it,
then the committer assigns the issue to the contributor. So when your
colleague contributes the next version of the patch then it should be
assigned to him. Committers add new Jira contributors as needed.
Cheers,
[
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-defa
Affects 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
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 a
[
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
: documentation
Affects Versions: site
Reporter: Doug Cutting
Assignee: Doug Cutting
Fix For: site
A number of subprojects have left Hadoop yet the website's not been fully
updated to reflect that.
--
This message is automatically generated by JIRA.
-
Yo
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 n
+1
I verified the checksum & signature and ran some of the example
programs. I also ran RAT to check that sources are licensed correctly.
I only examined the merged artifact. Do we need to release the others?
The out-of-box experience isn't great. There's no documentation at the
top-level
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 we
Allen Wittenauer wrote:
My main point was that suddenly people seem to be hot to declare something 1.0.
I'm trying to understand why [...]
My rationale for suggesting a release named 1.0 was that I prefer that
release numbers say something about compatibility. The compatibility
rules we've
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 discussion,
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 n
Chris Douglas wrote:
- de-deprecate "classic" mapred APIs (no Jira issue yet)
Why?
So that folks can be told that if their code compiles without
deprecation warnings against 1.0 then it should work for all 1.x releases.
I don't mind releasing 1.0 with the classic APIs. Given the installe
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 maki
Chris Douglas wrote:
Spending the next few months voting and arguing on which
patches make it into "new" 0.20 (branched in 2008) instead of
addressing these issues is *not* progress. I strongly oppose this.
If it takes months, it is a failure. It should take weeks, if that.
Thus far the chang
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
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
Allen Wittenauer wrote:
The fact that there are a *ton*
of admin tool changes/fixes/additions in the Yahoo! Distribution of 0.20
(and quite a few in CDH) should be the big hint that Apache 0.20 is *not*
1.0.
Right. I'm proposing we make a 1.0 release that tries to match what
folks are actual
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 change
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 r
[
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 d
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
This is an
: 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 im
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 http://java.sun.com/docs/codeconv/html/CodeConventions.doc6
Can another committer please review this issue?
https://issues.apache.org/jira/browse/HADOOP-6318
Thanks,
Doug
Reporter: Doug Cutting
The Serialization interface should permit one to create raw comparators.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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
Allen Wittenauer wrote:
Oh, I completely understand. I'm just throwing in a non-developer's
opinion... because I'm sure I'm not the only one expecting/assuming that 1.0
== completely stable.
If we have to live up to that expectation then we might never release
1.0! Frankly, I fear the long
Allen Wittenauer wrote:
This is just so disappointing and, quite frankly, makes 1.0 less than useful
for Real Work. Great, the APIs don't change but you still have the same
problems of getting data on/off the grid without upgrading your clients
every time.
To me, without wire compatibility,
Sanjay Radia wrote:
Both Facebook (Dhruba tells me) and Yahoo are suffering badly from the
lack of wire compatibility - a major motivaiton
for Yahoo to develop Avro.
Indeed. Wire compatibility is a crucial feature that we should release
as soon as possible. Perhaps before 1.0 if 1.0 slips,
[
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!
> bu
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 p
Sanjay Radia wrote:
I propose that we honor the compatibility of stable interfaces from
release 0.21 onwards;
i.e. apply the same post 1.0 rules to pre-1.0 releases.
I think that makes 0.21 effectively 1.0. The hallmark of 1.0 will be
our promise not to change APIs incompatibly until 2.0.
[
https://issues.apache.org/jira/browse/HADOOP-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting reopened HADOOP-6190:
--
Oops. I accidentally linked to lucene's mail archives! I fixed that and will
wait unt
[
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 for
Apache Wiki wrote:
when the word "Apache" does not appear on the main wiki page, that is a problem.
Thanks for catching that, Greg!
Doug
add Avro-based RPC serialization
Key: HADOOP-6170
URL: https://issues.apache.org/jira/browse/HADOOP-6170
Project: Hadoop Common
Issue Type: New Feature
Reporter: Doug Cutting
Assignee
Giridharan Kesavan wrote:
I agree with you on this;
We have some common places on people server
people.apache.org/repo and people.apache.org/repository but I've not seen any ivy artifacts being published there.
Writing things there causes them to be published to repo{1,2}.maven.org.
http://ww
Todd Lipcon wrote:
- Whenever a task will need to touch both Common and one of the components
(Mapred/HDFS) should there be two JIRAs or is it sufficient to have just one
"HADOOP" JIRA with separate patches uploaded for the two repositories?
Two Jiras, I think. In the long run, such issues sho
84 matches
Mail list logo
