The output on MAPREDUCE-4094 is no longer available, but a failed job
during an integration test could be traced to nondeterminism anywhere
in that chain. The "flakiness" you observe is common to many Hadoop
integration tests.
The purpose of the test is to verify that 1) the merge works when some
hat is possible(either tuning some of
> the parameters or increasing child JVM memory?)
>
> Thanks
> -- Asokan
> ________
> From: Chris Douglas [cdoug...@apache.org]
> Sent: Thursday, June 07, 2012 9:02 PM
> To: common-dev@hadoop.apache.org
>
+1 (binding)
Looks like your key isn't in the file:
https://svn.apache.org/repos/asf/hadoop/common/dist/KEYS Could you add
it? Signature is good (from pgp.mit.edu) and checksums match. Ran some
of the unit tests, looked through the changelog and repo log, looks
good.
There's a -bin target and ano
Konstantin-
There's no debate on the necessity of CI and related infrastructure to
support the platform well. Suresh outlined the support to effect this
here: http://s.apache.org/s1
Is the commitment to establish this infrastructure after the merge
sufficient? -C
On Fri, Mar 1, 2013 at 12:18 PM,
On Fri, Mar 1, 2013 at 1:57 PM, Konstantin Shvachko
wrote:
> Commitment is a good thing.
> I think the two builds that I proposed are a prerequisite for Win support.
> If we commit windows patch people will start breaking it the next day.
> Which we wont know without the nightly build and wont be
+1
Verified checksums and signatures, ran some tests, built the tarball. -C
On Thu, Apr 11, 2013 at 12:55 PM, Thomas Graves wrote:
> I've created a release candidate (RC0) for hadoop-0.23.7 that I would like
> to release.
>
> This release is a sustaining release with several important bug fixes
+1
Verified checksum, signatures. Ran some tests, built the package. -C
On Fri, Apr 12, 2013 at 2:56 PM, Arun C Murthy wrote:
> Folks,
>
> I've created a release candidate (RC2) for hadoop-2.0.4-alpha that I would
> like to release.
>
> The RC is available at:
> http://people.apache.org/~acmur
On Wed, May 1, 2013 at 6:24 PM, Arun C Murthy wrote:
> Having a strict policy leads to all sorts of further dialogues and issues we
> could do well without.
+1
Can anyone remember why we vote on release plans? -C
On Thu, May 2, 2013 at 2:11 AM, Konstantin Shvachko
wrote:
> On Thu, May 2, 2013 at 12:07 AM, Chris Douglas wrote:
>> Can anyone remember why we vote on release plans? -C
>
> To vote on features to include in the release.
Since most features are developed in branches (requiri
+1 on hadoop-1.2.0.tar.gz (verified checksums, signature, ran some unit tests)
but hadoop-1.2.0-bin.tar.gz is missing the source code and can't be built. -C
On Mon, May 6, 2013 at 11:11 AM, Matt Foley wrote:
> Hi all,
> I have posted the signed tarballs for Hadoop 1.2.0-rc1 at
> http://people.ap
t;binaries") and deliberately excludes the source
>> and docs, for those who wish a smaller tarball of binaries only. The
>> artifacts in both are from the same build.
>>
>> So I'll take your +1 on the source tarball :-)
>> Thanks,
>> --Matt
>>
>&
e the
> project, and certainly goes against the tradition of common usage in
> opensource projects, including many Apache projects.
>
> Respectfully,
> --Matt
>
>
>
> On Mon, May 13, 2013 at 2:01 PM, Chris Douglas wrote:
>
>> Thanks, Matt. As always, your work o
and run a vote again.
>
> Regardless, I will going forward change the build.xml file to produce a
> pure source tarball so that can be the unambiguous subject of the vote.
>
> Roy, if you're listening in, can you please say whether I need to re-do
> this vote?
>
> Than
Added to HADOOP, HDFS, MAPREDUCE, and YARN. -C
On Tue, May 14, 2013 at 11:03 AM, Konstantin Boudnik wrote:
> I'd like to spin-off a bugfix release for 2.0.4-alpha containing fix for
> MAPREDUCE-5240
> Vinod has the fix on branch-2 already, so it seems like a no-brainer backport.
>
> However, th
+1 (binding) on the proposal.
However, the value we get from these "release plan" votes is dubious,
to put it mildly. The surrounding discussion has cost more than it is
worth, and votes on executive summaries of releases discourage the
sort of detailed collaboration we're trying to create. It rep
The "release plan" vote is not binding in any way. Nobody "lost" a
vote, or risks having an outcome reversed, because there are no
consequences to these exercises.
Konstantin, I've been trying to tell you for more than a week that you
can go forward without anyone's blessing or consent. There are
+1
Thanks for taking care of this, Matt. -C
On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
> Hi all,
> This has been a side topic in several email threads recently. Currently we
> have an ambiguity. We have a tradition in the dev community that any
> committer can create a branch, and prop
+1
Checksum and signature match, ran some unit tests, verified w/ a diff
of release-2.0.4-alpha that the release contains MAPREDUCE-5240 and
HADOOP-9407, plus some fixups to the release notes. -C
On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik wrote:
> All,
>
> I have created a release candi
On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy wrote:
> Why not include MAPREDUCE-4211 as well rather than create one release per
> patch?
>From Cos's description, it sounded like these were backports of fixes
to help Sqoop2 and fix some build issues. If it's not just to fixup
leftover bugs in
n. I changed my vote instead of trusting you. -C
> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy wrote:
>> > Why not include MAPREDUCE-4211 as well rather than create one release per
>> > patch?
>>
>>
based on recent experience
I don't expect you to forgo it. I'd be happy to learn my caution is
unnecessary. -C
>> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy
>> >> wrote:
>> >
; Can we limit the vote thread to the merits of the release then?
Happily.
> That sound like adding an insult to injury, if my forth-language skills do not
> mislead me.
They do mislead you, or I've expressed the point imprecisely. We can
take this offline. -C
>> >> > On
+1
Checksum and signature match, ran some unit tests, checked diff
against 2.0.4-alpha.
Thanks for seeing this through, Cos. -C
On Mon, Jun 3, 2013 at 1:13 PM, Alejandro Abdelnur wrote:
> +1 RC2. Verified MD5 & signature, checked CHANGES.txt files, built,
> configured pseudo cluster, run a coup
+1
Checksum and signature match, ran some tests. -C
On Mon, Jun 3, 2013 at 1:19 PM, Sandy Ryza wrote:
> +1 (non-binding). Did a full build from source and ran a few sample jobs
> on a pseudo-distributed cluster.
>
> -Sandy
>
>
> On Mon, Jun 3, 2013 at 11:29 AM, Kihwal Lee wrote:
>
>> +1 I've d
> How about pre-announce a planned deletion some months ahead, give people
> time to migrate off
If the repository has been cloned, are there any operations that
require the remote? We could leave the old mirror there to be polled
for updates- which it will never have- but I was under the impressi
+1
>> * Should we integrate with the 0.18 branch, or just put our changes into
>> the
>> 0.18.3 release? We're not sure if there are plans for further releases on
>> the 0.18 branch.
This will not be committed to the 0.18 branch, even if there is an
0.18.4 release. If you wanted to post an 0.18 comp
+1
On Wed, Aug 12, 2009 at 4:04 PM, Owen O'Malley wrote:
> All,
> After the discussion settled last time, it seems that HDFS needs more time
> to settle append and sync. Therefore, I'd like to propose a freeze time of
> 4:30 pst on 18 Sep for making the 0.21 branch for Common, HDFS, and
> MapRed
On Mon, Dec 7, 2009 at 2:27 PM, Allen Wittenauer
wrote:
> On 12/7/09 2:00 PM, "Sanjay Radia" wrote:
>> Allen raises a good point that the rest of the community may not need
>> some of the features that Yahoo finds useful internally.
>
> FWIW, I have no real issues with the change itself. I'm muc
> Thanks Tom for stepping up to play the RM role for a 0.21.
+1 Thanks Tom.
> Regarding Steve's call for what we can offer Tom to help along the
> release, the little flea hbase can test its use case on 0.21.0
> candidates and we can probably take on a few of the HDFS blockers. I
> also like Ste
> My latest proposal, a 1.0 branch based on 0.20, contains two questions:
>
> 1. Should we make an Apache release that more closely corresponds to what
> folks are using in production today (and will be using for a while yet)?
>
> 2. If we're considering the 0.20 mapreduce and filesystem APIs to be
> Thus far the changes suggested for a 1.0 branch are:
> - de-deprecate "classic" mapred APIs (no Jira issue yet)
Why? Tom and Owen's proposal preserves compatibility with the
deprecated FileSystem and mapred APIs up to 1.0. After Tom cuts a
release- from either the 0.21 branch or trunk- then iss
>>> - 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.
Deprecation warnings aren't only fair notice that the API may go away.
The classic
+1 -C
On Thursday, April 1, 2010, Giridharan Kesavan wrote:
>
> I would like call for a vote to created a development branch of common
> trunk to work on mavenizing hadoop common.
>
> -Giri
>
le, performance or compatibility with future
features may be limited if they insist on the "classic" APIs. -C
> Daniel
>
> On 04/01/10 19:23, Chris Douglas wrote:
>>>>>
>>>>> - de-deprecate "classic" mapred APIs (no Jira issue yet)
>>&
> Actually, from my perspective, re the 0.20 branch, they are not preferred
> alternatives and are not complete as more were introduced into .21 (of which
> many are wrappers around the stable apis for sake of transition).
Sorry, I must have been unclear, because this is part of the argument.
Fi
> We've long-delayed declaring 1.0 because we were afraid to commit to
> supporting a given API for a longer term. Now folks are willing to make
> that long-term commitment to an API, yet seem reluctant to call it 1.0.
The commitment is to the new APIs. "Folks" are reluctant to cut a
release with
This is great. Thanks, Todd. -C
On Wed, Jan 5, 2011 at 12:36 PM, Todd Lipcon wrote:
> I know many people use git, so wanted to share a neat tip I figured out this
> morning that lets you graft the pre-split history into the post-split
> repositories. I'm using git 1.7.1, not sure how new these fe
It's used to align input splits of the SequenceFile. A reader can
start at an arbitrary offset, then find the boundary of the next block
of records by looking for the sync marker defined in the header. -C
On Mon, Mar 21, 2011 at 7:40 AM, Weishung Chung wrote:
> Hello my fellow Hadoop users/develo
On Fri, Apr 22, 2011 at 10:17 PM, Allen Wittenauer
wrote:
> Could someone actually take the branch and try to install from
> scratch? i.e., not copy a pre-existing config. I found a multitude of
> problems with 203 doing this, but haven't had a chance to file JIRAs for all
> of them.
+1
Signature matches, md5/sha1 match. Also tried a basic HDFS upgrade
from 0.20.2 to 0.20.203 with fresh configs on a single node: all OK,
including rollback to 0.20.2. -C
On Fri, Apr 29, 2011 at 4:09 PM, Owen O'Malley wrote:
> I think everything is ready to go on the 0.20.203.0 release. It incl
Yes to both. I haven't tested the concat bzip2 support, but I've heard
it's broken. The commit log and release note for the issue are correct
on HADOOP-6835.
You'll make me regret saying this, but always feel free to edit JIRA
titles that don't accurately reflect the content of the issue. -C
On M
Wow, this happened quickly.
Owen, could you please create a Wiki describing the proposal and
cataloging infra references so others can understand the
implementation in detail? Even after reading this thread, I'm still
confused what changes this proposes and how the integration works. A
document pa
What does it mean for the project to "retire... and donate [the
plugin] to the Mojohaus project"? The plugin will still be available,
but not maintained by Apache Maven?
Unless there is a satisfactory replacement for eclim, I'm stuck with
eclipse... -C
On Wed, Oct 7, 2015 at 2:31 PM, Andrew Wang
nges
>>and uncertainties in where and how it should go, thus more risk in
>>stalling.
>>
>>>> If the encryption libraries are the only ones you're interested in
>>>>pulling out, then Apache Commons does seem like a better target than a
>>>>separa
CTR is- and always has been- admissible in a branch.
On Wed, Mar 23, 2016 at 2:11 PM, Steve Loughran wrote:
> Given that only one +1 is needed to merge a non-branch patch, he could in
> theory convert the entire branch into a single .patch for review. Not that
> I'd encourage that, just observi
On Sat, Mar 26, 2016 at 7:08 AM, Steve Loughran wrote:
> Oh,I concur: but as we allow a single +1 for stuff done on, say, github,
> we've actually got a higher standard for merging in patches from forks within
> the ASF repo than there are from outside.
The standard is the same. Merging a major
If we're not starting branch-3/trunk, what would distinguish it from
trunk/trunk-incompat? Is it the same mechanism with different labels?
That may be a reasonable strategy when we create branch-3, as a
release branch for beta. Releasing 3.x from trunk will help us figure
out which incompatibiliti
I unsubscribed Randy from common-dev@. -C
On Thu, May 5, 2016 at 6:36 AM, Mark Holderbaugh
wrote:
> FYI Randy is no longer with Yahoo.I will ping Yahoo Inc IT to try and get his
> account to stop responding
> It will also be great if a moderator for common-dev and maybe other email
> lists to
Reading through HDFS-9924, a request for a design doc- and a -1 on
committing to trunk- was raised in mid-May, but commits to trunk
continued. Why is that? Shouldn't this have paused while the details
were discussed? Branching is neutral to the pace of feature
development, but consensus on the resu
+1 (binding)
Checksum and signature match, brought up a single-node cluster, ran
some sample jobs. -C
On Wed, Jul 24, 2013 at 2:08 PM, Matt Foley wrote:
> Colleagues,
> This is a stabilization release of the Hadoop-1.2 codeline. It has 18
> patches over the 1.2.0 release, which may be seen in t
Done. -C
On Fri, Aug 23, 2013 at 8:30 PM, Konstantin Boudnik wrote:
> Can anyone with admin rights in YARN JIRA project release 2.0.6-alpha version?
>
> Thanks,
> Cos
>
> On Fri, Aug 23, 2013 at 11:44AM, Konstantin Boudnik wrote:
>> All,
>>
>> I have pushed the bits of 2.0.6-alpha into the open
On Tue, Sep 3, 2013 at 5:20 AM, Larry McCay wrote:
> One outstanding question for me - how do we go about getting the branches
> created?
Once a group has converged on a purpose- ideally with some initial
code from JIRA- please go ahead and create the feature branch in svn.
There's no ceremony. -
+1
Verified checksum and signature, built tarball, ran some unit tests. -C
On Mon, Oct 7, 2013 at 12:00 AM, Arun C Murthy wrote:
> Folks,
>
> I've created a release candidate (rc0) for hadoop-2.2.0 that I would like to
> get released - this release fixes a small number of bugs and some
> proto
+1 (binding)
Verified checksum, signature. Built from src, poked at single-node
cluster, ran some unit tests. -C
On Tue, Feb 11, 2014 at 6:49 AM, Arun C Murthy wrote:
> Folks,
>
> I've created a release candidate (rc0) for hadoop-2.3.0 that I would like to
> get released.
>
> The RC is availabl
On Fri, May 30, 2014 at 11:05 PM, Niels Basjes wrote:
> How would someone create the situation you are referring to?
By adopting a naming convention where the filename suffix doesn't
imply that the raw data are compressed with that codec.
For example, if a user named SequenceFiles foo.lzo and fo
fter the change, it
could spuriously return false based on the suffix of the input files.
In the prenominate example, SequenceFile is splittable, even if the
codec used in each block is not. -C
> Niels
> On May 31, 2014 11:12 PM, "Chris Douglas" wrote:
>
>> On Fri, May 30, 201
On Fri, Jun 6, 2014 at 4:03 PM, Niels Basjes wrote:
> and if you then give the file the .gz extension this breaks all common
> sense / conventions about file names.
That the suffix for all compression codecs in every context- and all
future codecs- should determine whether a file can be split is
On Wed, Jun 11, 2014 at 1:35 AM, Niels Basjes wrote:
> That's not what I meant. What I understood from what was described is that
> sometimes people use an existing file extension (like .gz) for a file that
> is not a gzipped file.
Understood, but this change also applies to other loaded codecs,
On Fri, Jun 13, 2014 at 2:54 AM, Niels Basjes wrote:
> Hmmm, people only look at logs when they have a problem. So I don't think
> this would be enough.
This change to the framework will cause disruptions to users, to aid
InputFormat authors' debugging. The latter is a much smaller
population and
+1 -C
On Tue, Jun 24, 2014 at 1:53 AM, Arun C Murthy wrote:
> Folks,
>
> As discussed, I'd like to call a vote on changing our by-laws to change
> release votes from 7 days to 5.
>
> I've attached the change to by-laws I'm proposing.
>
> Please vote, the vote will the usual period of 7 days.
[moving to common-dev@]
The 80 character limit is for legibility across dev environments. If
it's impeding that goal in bash, then nobody will insist on it.
Since HADOOP-9902 rewrites most of this code, the particular cases can
be worked through in that JIRA. -C
On Sat, Jul 26, 2014 at 12:20 PM,
+1 -C
On Fri, Aug 8, 2014 at 7:57 PM, Karthik Kambatla wrote:
> I have put together this proposal based on recent discussion on this topic.
>
> Please vote on the proposal. The vote runs for 7 days.
>
>1. Migrate from subversion to git for version control.
>2. Force-push to be disabled on
On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang wrote:
> Not to derail the conversation, but if CHANGES.txt is making backports more
> annoying, why don't we get rid of it? It seems like we should be able to
> generate it via a JIRA query, and "git log" can also be used for a quick
> check (way faster
On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer wrote:
> We’ll also need to get much more strict about Fix Version really only listing
> the earliest version. Many of list (next release) + (trunk), myself
> included, which after looking through some of the commit docs, is not correct.
Is thi
Particularly since 9820 isn't in the contiguous range of ports in
HDFS-9427, is there any value in this change?
Let's change it back to prevent the disruption to users, but
downstream projects should treat this as a bug in their tests. Please
open JIRAs in affected projects. -C
On Tue, Jan 9, 20
fects of reverting as well as incompatible minor release change. Thanks
>
> Regards,
> Eric
>
> From: larry mccay
> Date: Wednesday, January 10, 2018 at 10:53 AM
> To: Daryn Sharp
> Cc: "Aaron T. Myers" , Eric Yang ,
> Chris Douglas , Hadoop Common <
> co
that serious, why not fixing it in
>4.0.0 and declare 3.x as dead?
>- It seems obvious that no one has seriously tested it so that the
>problem is not uncovered until now. Are there bugs in our current release
>procedure?
>
>
> Thanks
> Tsz-Wo
>
>
>
&g
. Users expect
>> 3.0.0 and 3.0.1 are compatible. How could we explain 3.0.0 and 3.0.1 are
>> incompatible due to convenience?3.2) Revert it in 4.0.0. There is no
>> compatibility issue since 3.0.0 and 4.0.0 are allowed to have incompatible
>> changes according to our policy.
>
+1 Looking forward to this. -C
On Fri, Jan 26, 2018 at 7:28 AM, Arun Suresh wrote:
> Hello yarn-dev@
>
> Based on the positive feedback from the DISCUSS thread [1], I'd like to
> start a formal vote to merge YARN-6592 [2] to trunk. The vote will run for 5
> days, and will end Jan 31 7:30AM PDT.
>
On Fri, Feb 2, 2018 at 10:22 AM, Arpit Agarwal wrote:
> Do you plan to roll an RC with an uncommitted fix? That isn't the right
> approach.
The fix will be committed to the release branch. We'll vote on the
release, and if it receives a majority of +1 votes then it becomes
3.0.1. That's how the
branch-3 has reappeared. Filed INFRA-16086 [1]. -C
[1]: https://issues.apache.org/jira/browse/INFRA-16086
On Wed, Jan 17, 2018 at 12:32 PM, Jason Lowe wrote:
> I filed INFRA-15859 to have branch-3 deleted.
>
> Jason
>
> On Wed, Jan 17, 2018 at 1:23 PM, Eric Payne <
> eric.payne1...@yahoo.com.in
On Mon, Mar 5, 2018 at 1:24 PM, Owen O'Malley wrote:
> The Apache Release Process
> https://www.apache.org/legal/release-policy.html says
> that we should only keep the latest release on each branch. That would take
> us to:
>
>
>- hadoop-1.2.1
>- hadoop-2.6.5
>- hadoop-2.7.5
>- ha
[Cross-posting, as this affects the rest of the project]
Hey folks-
As discussed last month [1], the HDFS build hasn't been healthy
recently. We're dedicating a bug bash to stabilize the build and
address some longstanding issues with our unit tests. We rely on our
CI infrastructure to keep the p
Found a meetup alternative (thanks Subru):
https://meetingstar.io/event/fk13172f1d75KN
So we can get a rough headcount, please add (local) if you plan to
attend in-person. -C
On Mon, Mar 5, 2018 at 4:03 PM, Chris Douglas wrote:
> [Cross-posting, as this affects the rest of the project]
>
eId=75965105
On Tue, Mar 6, 2018 at 7:48 PM, Chris Douglas wrote:
> Found a meetup alternative (thanks Subru):
> https://meetingstar.io/event/fk13172f1d75KN
>
> So we can get a rough headcount, please add (local) if you plan to
> attend in-person. -C
>
>
> On Mon,
here.
>
> Thanks,
>
> Junping
>
> 2018-03-05 16:03 GMT-08:00 Chris Douglas :
>
>> [Cross-posting, as this affects the rest of the project]
>>
>> Hey folks-
>>
>> As discussed last month [1], the HDFS build hasn't been healthy
>> r
. -C
[1]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75965105
> 2018-03-05 16:03 GMT-08:00 Chris Douglas :
>
>> [Cross-posting, as this affects the rest of the project]
>>
>> Hey folks-
>>
>> As discussed last month [1], the HDFS build hasn't been heal
We're using a shared doc to track work in progress, PA/review ready,
and committed [1]. -C
[1]: https://s.apache.org/RLlx
On Mon, Mar 12, 2018 at 9:17 AM, Chris Douglas wrote:
> On Fri, Mar 9, 2018 at 7:52 PM, 俊平堵 wrote:
>> Thanks for organizing this, Chris! Please let me know if
sue, but will double check. Let me know if there are
> more meetups planned in the near future and we can use this.
>
> Thanks
> +Vinod
>
> On Mar 6, 2018, at 7:48 PM, Chris Douglas wrote:
>
> Found a meetup alternative (thanks Subru):
> https://meetingstar.io/event/fk1
>
> I also deleted the obsolete md5 files and added the preferred sha256 files.
>
> .. Owen
>
> On Mon, Mar 5, 2018 at 3:23 PM, Chris Douglas wrote:
>
>> On Mon, Mar 5, 2018 at 1:24 PM, Owen O'Malley
>> wrote:
>> > The Apache Release Process
>> &g
Thanks, Allen.
On Thu, Mar 15, 2018 at 10:20 AM, Iñigo Goiri wrote:
>> * It ALWAYS applies HADOOP-14667.05.patch prior to running. As a result,
>> this is only set up for trunk with no parameterization to run other
>> branches.
I tried to get this running in my environment a few weeks ago, but
They've been failing for a long time. It can't install bats, and
that's fatal? -C
On Tue, May 15, 2018 at 9:43 AM, Allen Wittenauer
wrote:
>
>
> FYI:
>
> I’m going to disable the branch-2 nightly jobs.
> -
> To unsubscribe, e-mai
re [1]. -C
[1]: https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/
On Tue, May 15, 2018 at 10:27 AM, Allen Wittenauer
wrote:
>
>> On May 15, 2018, at 10:16 AM, Chris Douglas wrote:
>>
>> They've been failing for a long time. It can't i
There's not a lot of (required) ceremony. Any committer can create the
branch, including branch committers after the PMC adds them (see
bylaws [1]). -C
[1]: http://hadoop.apache.org/bylaws.html
On Thu, May 17, 2018 at 9:16 AM, Steve Loughran wrote:
> Now, what's next? I know we have the normal v
I had the same problem. Infra was able to add them, but I kept getting
an error. -C
On Tue, Jul 19, 2016 at 2:29 PM, Zheng, Kai wrote:
> Hi,
>
> I tried many times in the week at different time but just found it's not
> possible to add more HDFS contributors. I can add some Hadoop ones, though.
I agree with Konst. The virtues of branching (instead of releasing
from trunk) and using the version suffix for the 3.x releases are lost
on me. Both introduce opportunities for error, in commits, in
consistent JIRA tagging, in packaging...
We can mark stability on the website. If someone builds a
> I'm certainly open to alternate proposals for versioning and fix versions,
> but to reiterate, I like this versioning since it imitates other enterprise
> software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
> 3.0.0-alpha1 will be immediately familiar to end users. Conversel
+1 (also on JIRA) -C
On Wed, Sep 7, 2016 at 6:44 AM, Allen Wittenauer
wrote:
>
> I’d like to call for a vote to run for 5 days (ending Mon 12, 2016
> at 7AM PT) to merge the HADOOP-13341 feature branch into trunk. This branch
> was developed exclusively by me. As usual with large shel
Sure, I'll revert. Sorry, I'd only checked the main page, looked close
enough. -C
On Tue, Sep 27, 2016 at 10:34 AM, Andrew Wang wrote:
> Can we revert that change until we can get the site fixed?
>
> On Tue, Sep 27, 2016 at 10:06 AM, Steve Loughran
> wrote:
>
>> Things aren't laying out very wel
Reverted, resized to the same height as the original, pushed. -C
On Tue, Sep 27, 2016 at 11:27 AM, Chris Douglas wrote:
> Sure, I'll revert. Sorry, I'd only checked the main page, looked close
> enough. -C
>
> On Tue, Sep 27, 2016 at 10:34 AM, Andrew Wang
> wrote:
>
+1 Verified checksum and signature. Unpacked the jar, started
single-node HDFS cluster, did some cursory checks.
Read through the commit log from 2.6.4; particularly happy to see
HADOOP-12893. -C
On Tue, Sep 27, 2016 at 1:28 PM, Sangjin Lee wrote:
> Hi folks,
>
> I have created a release candida
Sorry, I'd missed the end of the EOL discussion thread.
As several people have pointed out, this is unenforceable. The release
dates on the front page are a decent signal for liveness... do we need
something more formal? All these hypothetical situations would be
decided with more context. The "go
On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee wrote:
> The security patch for the 2.6.x line is a case in point. Without any
> guideline, we would start with "What should we do for 2.6.x? Should we
> continue to patch it?" With this guideline, the baseline is already "it's
> been 2 years since 2.6.
Thanks for all your work on this, Andrew. It's great to see the 3.x
series moving forward.
If you were willing to modify the release notes and add the LICENSE to
the jar, we don't need to reset the clock on the VOTE, IMO.
What's the issue with the minicluster jar [1]? I tried to reproduce,
but ha
On Mon, Jan 23, 2017 at 9:32 PM, Allen Wittenauer
wrote:
> The problem here is that there is a 'license' directory and a file called
> 'LICENSE'. If this gets extracted by jar via jar xf, it will fail. unzip
> can be made to extract it via an option like -o. To make matters worse, none
> of
On Wed, Jan 25, 2017 at 11:42 AM, Andrew Wang wrote:
> Chris and Karthik, could you clarify the contingency of your votes? Is
> fixing just the release notes sufficient?
My +1 was not contingent on any changes.
The release is fine as-is. Fixing any subset of the release notes,
minicluster jar, a
On Tue, Mar 28, 2017 at 3:04 PM, Andrew Wang wrote:
> There's no mention of the convenient "Embedded messages are compatible with
>> bytes if the bytes contain an encoded version of the message" semantics in
>> proto3.
>
>
> I checked the proto3 guide, and I think this is supported:
> https://deve
On Tue, Mar 28, 2017 at 4:18 PM, Andrew Wang wrote:
> Unfortunately, it sounds like these are intrinsic differences with PB3.
That's too bad... but possibly not fatal: most of the data we proxy
through client code is, if not opaque, it's at least immutable
(particularly tokens). If PB3 does suppo
On Wed, Mar 29, 2017 at 1:13 PM, Stack wrote:
> Is the below evidence enough that pb3 in proto2 syntax mode does not drop
> 'unknown' fields? (Maybe you want evidence that java tooling behaves the
> same?)
I reproduced your example with the Java tooling, including changing
some of the fields in t
1 - 100 of 192 matches
Mail list logo
