gt; > we're at and ship it ASAP.
>> >
>> > Jason
>> > (1) https://issues.apache.org/jira/issues/?jql=project%20in%
>> > 20%28hadoop%2C%20yarn%2C%20mapreduce%2C%20hdfs%29%
>> > 20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%202.8.0
>&
he latest major line every 6
>>> months,
>>> > and a maintenance release on a minor release (as there may be
>>> concurrently
>>> > maintained minor releases) every 2 months.
>>> >
>>> > A minor release line is EOLed 2 years after it is fir
Apologies for spamming this list. I meant to send it to Cloudera's HDFS
team. :)
On Fri, Oct 28, 2016 at 10:41 AM, Karthik Kambatla
wrote:
> (bcc: hdfs-dev@, rm-staff@, eng@, pe-team@, cert@, bd-staff@ - all the
> teams at Cloudera Daniel worked on)
>
> It gives me immense ple
(bcc: hdfs-dev@, rm-staff@, eng@, pe-team@, cert@, bd-staff@ - all the
teams at Cloudera Daniel worked on)
It gives me immense pleasure to announce that Daniel has been elected a
committer on the Apache Hadoop project.
Daniel joined the engineering team (HDFS and subsequently RM) last year and
ha
Is there value in releasing current branch-2.8? Aren't we better off
re-cutting the branch off of branch-2?
On Tue, Oct 25, 2016 at 12:20 AM, Akira Ajisaka
wrote:
> It's almost a year since branch-2.8 has cut.
> I'm thinking we need to release 2.8.0 ASAP.
>
> According to the following list, the
Never included the link :)
https://github.com/gezapeti/jira-comment-collapser
On Mon, Oct 17, 2016 at 6:46 PM, Karthik Kambatla
wrote:
> Hi folks
>
> Sorry for the widespread email, but thought you would find this useful.
>
> My colleague, Peter, had put together this chro
Hi folks
Sorry for the widespread email, but thought you would find this useful.
My colleague, Peter, had put together this chrome extension to collapse
comments from certain users (HadoopQA, Githubbot) that makes tracking
conversations in JIRAs much easier.
Cheers!
Karthik
Thanks for putting the RC together, Sangjin.
+1 (binding)
Built from source, deployed pseudo distributed cluster and ran some example
MR jobs.
On Fri, Oct 7, 2016 at 6:01 PM, Yongjun Zhang wrote:
> Hi Sangjin,
>
> Thanks a lot for your work here.
>
> My +1 (binding).
>
> - Downloaded both bina
>
>
> Here is just an idea to get started. How about "a minor release line is
> EOLed 2 years after it is released or there are 2 newer minor releases,
> whichever is sooner. The community reserves the right to extend or shorten
> the life of a release line if there is a good reason to do so."
>
>
Forking off this discussion from 2.6.5 release thread. Junping and Chris T
have brought up important concerns regarding too many concurrent releases
and the lack of EOL for our releases.
First up, it would be nice to hear from others on our releases having the
notion of EOL and other predictabilit
Since there is sufficient interest in 2.6.5, we should probably do it. All
the reasons Allen outlines make sense.
That said, Junping brings up a very important point that we should think of
for future releases. For a new user or a user that does not directly
contribute to the project, more stable
to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.
On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla wrote:
> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. Whi
version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________
> From: Karthik Kambatla
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-...@hadoop.apache.org; yarn-...@hadoop.apache.org;
> hdfs-dev@hadoop.apach
I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.
I am open to something like 2.98.x for alphas and 2.99.x for be
Inline.
>
>> BTW, I never see we have a clear definition for alpha release. It is
>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>> but sometimes means unstable in production quality (2.7.0). I think we
>> should clearly define it with major consensus so user won't
Inline.
> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>
Sounds reasonable.
>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>
Once
IIRR, the vote is on source artifacts and binaries are for convenience.
If that is right, I am open to either options - do another RC or continue
this vote and fix the binary artifacts.
On Tue, Jul 26, 2016 at 12:11 PM, Vinod Kumar Vavilapalli <
vino...@apache.org> wrote:
> Thanks Daniel and Wei
+1 (binding)
* Downloaded and build from source
* Checked LICENSE and NOTICE
* Pseudo-distributed cluster with FairScheduler
* Ran MR and HDFS tests
* Verified basic UI
On Sun, Jul 24, 2016 at 1:07 PM, larry mccay wrote:
> +1 binding
>
> * downloaded and built from source
> * checked LICENSE an
Thanks for clarifying Andrew. Inline.
On Mon, Jun 13, 2016 at 3:59 PM, Andrew Wang
wrote:
>
> On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla
> wrote:
>
>> I would like to understand the trunk-incompat part of the proposal a
>> little better.
>>
>> Is
significant:
>>> >> > - A lot of commits (incompatible, risky, uncompleted feature, etc.)
>>> have
>>> >> > to wait to commit to trunk or put into a separated branch that could
>>> >> delay
>>> >> > feature development progress as additional vote
oposal forces following these requirements and hence I like it more.
>
> Thanks,
>
> Junping
>
> From: Karthik Kambatla
> Sent: Friday, June 10, 2016 7:49 AM
> To: Andrew Wang
> Cc: common-...@hadoop.apache.org; hdfs-dev@hadoop.apache.or
Thanks for restarting this thread Andrew. I really hope we can get this
across to a VOTE so it is clear.
I see a few advantages shipping from trunk:
- The lack of need for one additional backport each time.
- Feature rot in trunk
Instead of creating branch-3, I recommend creating branch-3.
I am with Vinod on avoiding merging mostly_complete_branches to trunk since
we are not shipping any release off it. If 3.x releases going off of trunk
is going to help with this, I am fine with that approach. We should still
make sure to keep trunk-incompat small and not include large features.
On
Thanks Vinod. Not labeling 2.8.0 stable sounds perfectly reasonable to me.
Let us not call it alpha or beta though, it is quite confusing. :)
On Wed, Feb 3, 2016 at 8:17 PM, Gangumalla, Uma
wrote:
> Thanks Vinod. +1 for 2.8 release start.
>
> Regards,
> Uma
>
> On 2/3/16, 3:53 PM, "Vinod Kumar V
Filed https://issues.apache.org/jira/browse/INFRA-11136
On Mon, Jan 25, 2016 at 3:41 PM, Vinod Kumar Vavilapalli wrote:
> I believe this is still in place, though I am not sure how we can verify
> this (without doing a force-push of course)
>
> +Vinod
>
> > One thing that wasn't clear from the I
+1 on all counts.
One thing that wasn't clear from the INFRA announcement: are trunk,
branch-* branches protected against force-pushes in the new world? If not,
should we ask them to be locked up?
Thanks
Karthik
On Thu, Jan 14, 2016 at 10:26 PM, Vinod Kumar Vavilapalli <
vino...@apache.org> wrot
Hi folks
In the last few months, we have been shipping multiple releases -
maintenance and minor - elevating the quality and purpose of our releases.
With the increase in releases and related communication, I wonder if we
need to highlight release-related communication in some way. Otherwise, it
Did we consider cutting a branch-3 that borrows relatively compatible
patches from trunk to run the 3.x line? That said, I would like for us to
really tighten our compatibility policies and actually stick to them
starting the next major release.
On Wed, Nov 11, 2015 at 1:11 PM, Vinod Vavilapalli
I am really against the notion of calling x.y.0 releases alpha/beta; it is
very confusing. If we think a release is alpha/beta quality, why not
release it as x.y.0-alpha or x.y.0-beta, and follow it up eventually with
x.y.0 GA.
I am in favor of labeling any of the newer features to be of alpha/bet
I would like for us to make sure later maintenance releases are more stable
than previous ones. IMO, increasing stability is more important than the
timing of a release.
Will adding all the patches in 2.7.3 reduce the stability going from 2.7.2
to 2.7.3? If yes, can we just leave them for 2.8.0?
On Wed, Oct 14, 2015 at 4:28 PM, Allen Wittenauer wrote:
>
> If people want, I could setup a cut off of yetus master to run the jenkins
> test-patch. (multiple maven repos, docker support, multijdk support, … )
> Yetus would get some real world testing out of it and hadoop common-dev
> could sto
+1 (binding)
Ran a few MR jobs on a pseudo-distributed cluster on Java 8.
On Tue, Sep 22, 2015 at 8:09 AM, Masatake Iwasaki <
iwasak...@oss.nttdata.co.jp> wrote:
> +1(non-binding)
>
> - verified mds and signature of source and binary tarball
> - built from source tarball with -Pnative on CentOS
ill run for the usual 5 days.
>
> Thanks,
> Vinod
>
> PS: It took 2 months instead of the planned [1] 2 weeks in getting this
> release out: post-mortem in a separate thread.
>
> [1]: A 2.7.1 release to follow up 2.7.0
> http://markmail.org/thread/zwzze6cqqgwq4rmw
>
Huge +1
On Thursday, July 2, 2015, Chris Nauroth wrote:
> +1
>
> Thank you to Allen for the script, and thank you to Andrew for
> volunteering to drive the conversion.
>
> --Chris Nauroth
>
>
>
>
> On 7/2/15, 2:01 PM, "Andrew Wang" >
> wrote:
>
> >Hi all,
> >
> >I want to revive the discussion o
1.3 release, especially given that 1.2.1
> was Aug 2013 ….
> >
> > I guess we need a PMC member to declare a vote or whatever….
> >
> >
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
ention of working on the 1.3 release, especially given that 1.2.1
> was Aug 2013 ….
>
> I guess we need a PMC member to declare a vote or whatever….
>
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
> >> I would also like to support Karthik's proposal on the release thread
> > about
> > >> version numbering. 2.7.0 being "alpha" is pretty confusing since all
> of
> > the
> > >> other 2.x releases since GA have been stable. I think users would
> > prefer a
> > >> version like "2.8.0-alpha1" instead, which is very clear and similar
> to
> > >> what we did for 2.0 and 2.1. Then we release 2.8.0 when we're actually
> > >> stable.
> > >>
> > >> I don't know if it's retroactively possible to do this for 2.7.0, but
> > it's
> > >> something to consider for the next 2.7 alpha or beta or whatever.
> > >>
> >
> >
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
e predictable releases instead of holding up releases for ever.
>
> Thoughts?
>
> Thanks
> +Vinod
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
> Please try the release and vote; the vote will run for the usual 5 days.
>
> Thanks,
> Vinod
>
> [1]: A 2.7.1 release to follow up 2.7.0
> http://markmail.org/thread/zwzze6cqqgwq4rmw
>
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
d did a pass. In the unavoidable event
> that we find incompatibilities with 2.7.0, we can fix those in 2.7.1 and
> promote that to be the stable release.
>
Sounds reasonable.
>
> Thoughts?
>
> Thanks,+Vinod
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
deprecated
> at least for one major release before being removed."
>
> http://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/
> hadoop-common/Compatibility.html#Hadoop_Configuration_Files
>
> Is it applicable for unused properties?
> Can we remove unused properties right
f Jenkins doesn’t setup the
> environment correctly or leaks variables between runs. shellcheck prints
> out so many messages on the current code I’m surprised it doesn’t crash.
>
> On Mar 31, 2015, at 9:21 AM, Karthik Kambatla wrote:
>
> > Hi devs,
> >
> > I am su
N files,
but the test were run against one of the MR modules.
I suspect there is a race condition when there are multiple builds
executing on the same node, or remnants from a previous run are getting
picked up.
Filed HADOOP-11779 for this.
--
Karthik Kambatla
Software Engine
nd API level with the existing java code & JDK7+
> clusters.
>
> A classpath fix that is optional/compatible can then go out on the 2.x
> line, saving the 3.x tag for something that really breaks things, forces
> all downstream apps to set up new hadoop profiles, have separat
For instance, it would be great if we could maintain wire
> > compatibility between 2.x and 3.x, so rolling upgrades work. Keeping
> > branch-2 and branch-3 similar also makes backports easier, since we're
> > likely maintaining 2.x for a while yet.
> >
> > Please let me know any comments / concerns related to the above. If
> people
> > are friendly to the idea, I'd like to cut a branch-3 and start working on
> > the first alpha.
> >
> > Best,
> > Andrew
> >
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
who already has a
> patch sitting there for more than a year before. This may need us to
> collectively agree on some convention - the last comment says that the
> branch patch name should be in some format for this to work.
>
> Thanks
non-committer to review the patch?
> > Creating this thread to discuss these (and other that I sure missed)
> issues
> > and to combine multiple discussions into one.
> >
> > My personal opinion we should just stick to the tradition. Good or bad,
> it
> > worked f
would be great if we could maintain wire
> compatibility between 2.x and 3.x, so rolling upgrades work. Keeping
> branch-2 and branch-3 similar also makes backports easier, since we're
> likely maintaining 2.x for a while yet.
>
> Please let me know any comments / concerns re
>
> Folks,
>
> What is the current status of the 2.7 release? I know initially it started
> out as a "java-7" only release, but looking at the JIRAs that is very much
> not the case.
>
> Do we have a certain timeframe for 2.7 or is it time to discuss it?
&
not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
Folks,
I just renamed (1) the old HowToCommit to HowToCommitWithSvn, and (2) the
new HowToCommitWithGit to HowToCommit.
Thanks
Karthik
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
2014, at 11:09 AM, Sangjin Lee wrote:
> >
> > > If 2.7 is being positioned as the JDK7-only release, then it would be
> > good
> > > to know how 2.8 lines up in terms of timing. Our interest is landing
> the
> > > shared cache feature (YARN-1492)... Thanks.
&
Thanks for starting this thread, Arun.
Your proposal seems reasonable to me. I suppose we would like new features
and improvements to go into 2.8 then? If yes, what time frame are we
looking at for 2.8? Looking at YARN, it would be nice to get a release with
shared-cache and a stable version of re
+1 (binding) on the source tarball, would be nice to redo the binary
tarball.
- Stood up a pseudo-dist cluster, and ran some HDFS and MR jobs.
- The binary is about 40 MB larger than the previous release; it appears
the docs are copied over twice - share/doc/hadoop and share/hadoop. The
binary tar
[
https://issues.apache.org/jira/browse/HDFS-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved HDFS-7275.
Resolution: Duplicate
> Add TLSv1.1,TLSv1.2 to Htt
Looking at the patches, we might be able to get most of YARN-1492 in by the
end of next week. There would be a couple of security items still
remaining, but we can may be call the feature alpha-ready without them.
On Tue, Sep 23, 2014 at 4:25 PM, Chris Trezzo wrote:
> I would like to see the sha
rce tarball
> + successfully run apache-rat:check
> + checked CHANGES, LICENSE, README, NOTICE files.
> + built from source tarball
> + started pseudo cluster
> + run a couple of MR example jobs
> + basic test on HttpFS
>
> On Wed, Sep 10, 2014 at 10:10 AM, Karthik Kambatla
nt release. Filed HADOOP-11078 to track this.
>
> Regards,
> Akira
>
>
> (2014/09/09 0:51), Karthik Kambatla wrote:
>
>> +1 (non-binding)
>>
>> Built the source tarball, brought up a pseudo-distributed cluster and ran
>> a
>> few MR jobs. Verifie
+1 (non-binding)
Built the source tarball, brought up a pseudo-distributed cluster and ran a
few MR jobs. Verified documentation and size of the binary tarball.
On Fri, Sep 5, 2014 at 5:18 PM, Karthik Kambatla wrote:
> Hi folks,
>
> I have put together a release candidate (RC0) f
Hi folks,
I have put together a release candidate (RC0) for Hadoop 2.5.1.
The RC is available at: http://people.apache.org/~kasha/hadoop-2.5.1-RC0/
The RC git tag is release-2.5.1-RC0
The maven artifacts are staged at:
https://repository.apache.org/content/repositories/orgapachehadoop-1010/
You
Hi folks
Now that all issues with target 2.5.1 are committed, I am planning to cut
an RC for 2.5.1 this Friday. The fixes going into 2.5.1 are -
http://s.apache.org/2Mz
Are there any other "Blocker" issues that we would like to get into 2.5.1?
If there are any, please mark them as "Blocker" and t
sf?p=cloudstack.git;h=7260e8d
This is more concise and easier to look at than the Hudson list.
On Wed, Aug 27, 2014 at 10:48 AM, Karthik Kambatla
wrote:
> It appears the comments from Hudson on our JIRAs (post commits) are not
> setup by the INFRA team. Do we use any other scripts for this?
It appears the comments from Hudson on our JIRAs (post commits) are not
setup by the INFRA team. Do we use any other scripts for this? If yes, do
we want to fix those scripts or use svngit2jira?
On Wed, Aug 27, 2014 at 10:18 AM, Karthik Kambatla
wrote:
> The emails for commits apparently
at 1:40 AM, Karthik Kambatla
wrote:
> Oh.. a couple more things.
>
> The git commit hashes have changed and are different from what we had on
> our github. This might interfere with any build automations that folks
> have.
>
> Another follow-up item: email and JIRA integration
Oh.. a couple more things.
The git commit hashes have changed and are different from what we had on
our github. This might interfere with any build automations that folks
have.
Another follow-up item: email and JIRA integration
On Wed, Aug 27, 2014 at 1:33 AM, Karthik Kambatla
wrote:
>
Hi folks,
I am very excited to let you know that the git repo is now writable. I
committed a few changes (CHANGES.txt fixes and branching for 2.5.1) and
everything looks good.
Current status:
1. All branches have the same names, including trunk.
2. Force push is disabled on trunk, branch-2
gt; In my experience, especially when a project has committers new to git,
> force-push support causes more trouble than it's worth.
>
> -Todd
>
>
> On Tue, Aug 26, 2014 at 4:39 PM, Karthik Kambatla
> wrote:
>
> > Looks like our git repo is good to go.
> >
>
the branches
> are present. Also checked a few branches and the recent commit history
> matches our existing repo. Everything looks good so far.
>
>
> On Tue, Aug 26, 2014 at 1:19 PM, Karthik Kambatla
> wrote:
>
> > The git repository is now ready for inspection. I ll t
g.
Are we comfortable with making the git repo writable under these
conditions? I ll let other people poke around and report.
Thanks for your cooperation,
Karthik
On Tue, Aug 26, 2014 at 1:19 PM, Karthik Kambatla
wrote:
> The git repository is now ready for inspection. I ll take a look shortly,
&
The git repository is now ready for inspection. I ll take a look shortly,
but it would be great if a few others could too.
Once we are okay with it, we can ask it to be writable.
On Tuesday, August 26, 2014, Karthik Kambatla wrote:
> Hi Suresh
>
> There was one vote thread on w
ad-hoc basis. Was there any voting on this in PMC and should
> we have a vote to ensure everyone is one the same page on doing this and
> how to go about it?
>
> Regards,
> Suresh
>
>
> On Tue, Aug 26, 2014 at 9:17 AM, Karthik Kambatla
> wrote:
>
> > Last I heard,
Last I heard, the import is still going on and appears closer to getting
done. Thanks for your patience with the migration.
I ll update you as and when there is something. Eventually, the git repo
should be at the location in the wiki.
On Mon, Aug 25, 2014 at 3:45 PM, Karthik Kambatla
wrote
se
configs?
>
> Moreover, do we want to use "--author="Author Name "
> when committing on behalf of a particular contributor?
>
Fetching the email-address is complicated here. Should we use the
contributor's email from JIRA? What if that is not their @apache
uot;master" may be viewed as the official git way, but it doesn't have to be.
> For git-flow workflows (which we use in slider) master/ is for releases,
> develop/ for dev.
>
>
>
>
> On 24 August 2014 02:31, Karthik Kambatla wrote:
>
> > Couple of things:
Thanks Giri.
By the way, writes to svn are now disabled.
On Saturday, August 23, 2014, Giridharan Kesavan
wrote:
> I can take a look at this on Monday.
>
> -giri
>
>
> On Sat, Aug 23, 2014 at 6:31 PM, Karthik Kambatla >
> wrote:
>
> > Couple of things:
>
understand Giri maintains those builds, do we have anyone
else who has access in case Giri is not reachable? Giri - please shout out
if you can help us with this either on Sunday or Monday.
Thanks
Karthik
On Fri, Aug 22, 2014 at 3:50 PM, Karthik Kambatla
wrote:
> Also, does anyone know what
Also, does anyone know what we use for integration between JIRA and svn? I
am assuming svn2jira.
On Fri, Aug 22, 2014 at 3:48 PM, Karthik Kambatla
wrote:
> Hi folks,
>
> For the SCM migration, feel free to follow
> https://issues.apache.org/jira/browse/INFRA-8195
>
> Most of
Hi folks,
For the SCM migration, feel free to follow
https://issues.apache.org/jira/browse/INFRA-8195
Most of this is planned to be handled this Sunday. As a result, the
subversion repository would be read-only. If this is a major issue for you,
please shout out.
Daniel Gruno, the one helping us
Hi devs
Tsuyoshi just brought it to my notice that the published tarballs don't
have LICENSE, NOTICE and README at the top-level. Instead, they are only
under common, hdfs, etc.
Now that we have already announced the release and the jars/functionality
doesn't change, I propose we just update the
Filed https://issues.apache.org/jira/browse/INFRA-8195. I encourage folks
to watch the issue and at least some of us help with verifying the
migration moves everything.
On Sat, Aug 16, 2014 at 8:25 AM, Karthik Kambatla
wrote:
> Thanks everyone for voting. Here is my +1 (non-binding).
>
t;Hitesh Shah" wrote:
>
> > +1
> >
> > — Hitesh
> >
> > On 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 t
Using asynchronous loggers for improved performance sounds reasonable.
However, IMO we already log too much at INFO level (particularly YARN).
Logging more at DEBUG level and lowering the overhead of enabling DEBUG
logging is preferable.
One concern is the defaults. Based on what I read on the log
> Karthik.
>
> Arun
>
> On Aug 6, 2014, at 1:59 PM, Karthik Kambatla wrote:
>
> > Hi folks,
> >
> > I have put together a release candidate (rc2) for Hadoop 2.5.0.
> >
> > The RC is available at:
> http://people.apache.org/~kasha/hadoop-2.5.0-RC2/
>
compiled.
> Would you please generate documents with
> 'mvn site site:stage /path/to/deploy'?
>
> I'm +1 (non-binding) if the documents are included.
>
> Thanks,
> Akira
>
>
> (2014/08/12 13:49), Karthik Kambatla wrote:
>
>> I have updated the binar
Can someone please verify the signatures on the new binary and the old
source tarballs to make sure it is all good? If it is, I believe we can go
ahead and close the vote.
On Mon, Aug 11, 2014 at 9:49 PM, Karthik Kambatla
wrote:
> I have updated the binary tar ball to include the docs,
arball without modifying source code.
> +1(non-binding) to continue the voting.
>
> Thanks,
> - Tsuyoshi
>
> On Tue, Aug 12, 2014 at 3:47 AM, Karthik Kambatla
> wrote:
> > Thanks Akira for catching the missing docs. Let me work on *updating* the
> > binary tarball to i
pps/datanode/index.html
> ./share/hadoop/tools/sls/html/showSimulationTrace.html
>
> Karthik, could you create new tar ball with the documentations?
>
> Thanks,
> - Tsuyoshi
>
> On Thu, Aug 7, 2014 at 5:59 AM, Karthik Kambatla
> wrote:
> > Hi folks,
> >
> > I ha
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 trunk and branch-* branches. Applying
changes from any of trunk/branch
Thanks Steve. Including that in the proposal.
By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html),
I can't tell what kind of a vote this would be.
On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran
wrote:
> On 6 August 2014 22:16, Karthik Kambatla wrote:
>
&
+1 (non-binding)
Brought up a pseudo distributed cluster. Ran a few HDFS operations and a
couple of example MR jobs. Checked metrics being written out through
FileSink.
On Wed, Aug 6, 2014 at 1:59 PM, Karthik Kambatla wrote:
> Hi folks,
>
> I have put together a release candidate
ve it.
> > >
> > >
> > > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <
> aagar...@hortonworks.com>
> > > wrote:
> > >
> > > > +1 to voting on specific workflow(s).
> > > >
> > > >
> > > >
Hi folks,
I have put together a release candidate (rc2) for Hadoop 2.5.0.
The RC is available at: http://people.apache.org/~kasha/hadoop-2.5.0-RC2/
The RC tag in svn is here:
https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.5.0-rc2/
The maven artifacts are staged at:
https://reposito
t; 3. run the s3n Contract tests:
> > mvn test -Dtest=TestS3NContract\*
> > ...all passed
> >
> > 4. in hadoop-tools/hadoop-openstack -ran all the tests with
> auth-keys.xml
> > set to bind all non-contract tests to a public cloud &
> > contract-test-option
If we are to start a vote thread, will people prefer a vote thread that
includes potential workflows as well?
On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla wrote:
> Thanks for your opinions, everyone. Looks like most people are for the
> change and no one is against it. Let me start
+1 (non-binding)
Brought up a pseudo distributed cluster. Ran a few HDFS operations and a
couple of example MR jobs. Checked metrics being written out through
FileSink.
On Tue, Aug 5, 2014 at 5:37 PM, Karthik Kambatla wrote:
> Hi folks,
>
> I have put together a release candidate
velopment like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> development, because the cost of sending pull request is very low and
> >> its review board is great. One concern is that the development
> >> workflow can change and it can confuse us. What do you think?
This vote is cancelled due to the incompatible issue.
On Fri, Aug 1, 2014 at 5:28 PM, Karthik Kambatla wrote:
> Missed Andrew's email in the other thread. Looks like we might need
> HDFS-6793.
>
> I ll wait to see if others find any other issues, so I can address them
> al
Hi folks,
I have put together a release candidate (rc1) for Hadoop 2.5.0.
The RC is available at: http://people.apache.org/~kasha/hadoop-2.5.0-RC1/
The RC tag in svn is here:
https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.5.0-rc1/
The maven artifacts are staged at:
https://reposito
[
https://issues.apache.org/jira/browse/HDFS-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved HDFS-6717.
Resolution: Fixed
Fix Version/s: (was: 2.5.0)
2.6.0
Reverted
[
https://issues.apache.org/jira/browse/HDFS-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla reopened HDFS-6717:
Looks like this got mistakenly committed to branch-2.5, given this is a "Minor"
iss
1 - 100 of 129 matches
Mail list logo
