+1 (binding)
* Built from source
* Started a pseudo-distributed cluster with fairscheduler.
* Ran sample jobs
* Verified WebUI
On Wed, Mar 22, 2017 at 11:56 AM, varunsax...@apache.org <
varun.saxena.apa...@gmail.com> wrote:
> Thanks Junping for creating the release.
>
> +1 (non-binding)
>
> * Ve
t;
> > On Wed, Jan 25, 2017 at 11:14 AM, Karthik Kambatla
> > wrote:
> >
> >> Thanks for driving the alphas, Andrew. I don't see the need to restart
> the
> >> vote and I feel it is okay to fix the minor issues before releasing.
> >>
> >>
Thanks for driving the alphas, Andrew. I don't see the need to restart the
vote and I feel it is okay to fix the minor issues before releasing.
+1 (binding). Downloaded source, stood up a pseudo-distributed cluster with
FairScheduler, ran example jobs, and played around with the UI.
Thanks
Karthi
Given the discussions, I feel we are not ready for VOTE on this yet.
Sangjin, should we go back to the DISCUSS thread?
IMO, these are guidelines and not policies we want to enforce. Maybe, the
text should say something along the lines of: "The Hadoop community is
inclined to". And, maybe, a caveat
+1
I would also like to see some process guidelines. I should have brought
this up on the discussion thread, but I thought of them only now :(
- Is an RM responsible for all maintenance releases against a minor
release, or finding another RM to drive a maintenance release? In the past,
t
it in the discussion thread. Should
> we take it to a vote? Do we need additional discussions?
>
> Regards,
> Sangjin
>
> On Wed, Nov 9, 2016 at 11:11 PM, Karthik Kambatla
> wrote:
>
>> Fair points, Sangjin and Andrew.
>>
>> To get the ball rolling on this, I
Karthik Kambatla created HADOOP-13961:
-
Summary: mvn install fails on trunk
Key: HADOOP-13961
URL: https://issues.apache.org/jira/browse/HADOOP-13961
Project: Hadoop Common
Issue Type
Karthik Kambatla created HADOOP-13860:
-
Summary: ZKFailoverController.ElectorCallbacks should have a
non-trivial implementation for enterNeutralMode
Key: HADOOP-13860
URL: https://issues.apache.org/jira
Karthik Kambatla created HADOOP-13821:
-
Summary: Improve findbugs rules to not require trivially
overriding equals and hashCode methods
Key: HADOOP-13821
URL: https://issues.apache.org/jira/browse/HADOOP
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
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
Karthik Kambatla created HADOOP-13714:
-
Summary: Tighten up our compatibility guidelines for Hadoop 3
Key: HADOOP-13714
URL: https://issues.apache.org/jira/browse/HADOOP-13714
Project: Hadoop
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-dev@hadoop.apache.org; yarn-...@hadoop.apache.org;
> hdfs-...@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
Recently, Andrew Wang and I were at an academic conference where one of the
attendees (a grad student) was mentioning that his posts to the IRC channel
are never answered.
Personally, I haven't been using the IRC channel. Neither do I know anyone
who is actively monitoring it.
I am emailing to ch
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-dev@hadoop.apache.org; hdfs-...@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
I wonder if we should add another annotation between @Private and @Public.
Can that be @LimitedPrivate itself?
There are some APIs we shouldn't expect end-users to recompile even across
major versions (e.g. FileSystem, JobClient). On the other hand, requiring a
Yarn application to recompile seems
The naming scheme sounds good. Since we want to start out sooner, I am
assuming we are not limiting ourselves to two alphas as the email might
indicate.
Also, as the release manager, can you elaborate on your definitions of
alpha and beta? Specifically, when do we expect downstream projects to try
S: We also use gerrit, so that serializes our commits for us.
On Fri, Apr 22, 2016 at 2:04 PM, Karthik Kambatla
wrote:
> Owen, I agree force-pushes likely make for cleaner history, but they also
> allow losing commits in case of race conditions. Since the previous
> decision of disablin
pdates causes more pain than it helps.
>
> The much more important part is that someone should make tags for the
> recent releases in the "rel/*" namespace so that they can't be modified.
> I'd suggest at least:
>
> release-2.6.4
> release-2.7.2
>
&g
Recent changes to branch policies have affected this. Our trunk seems
protected, but not branch-* branches. I had filed INFRA-11236 to address
this. I can't ping on the JIRA anymore because comments from
non-contributors are disabled.
To prevent unintentional major messes, it is highly recommended
A feature branch seems reasonable for this work: multiple reviewable
patches that are meaningful only after all of them get in. I guess most
comments here that had concerns for a branch were primarily based on the
initial reasoning of not being able to find a reviewer.
Coming to RTC and CTR, I hav
I'm fine with dropping this step.
I can't help but bring it up again, shouldn't we drop the CHANGES.txt
altogether?
Get Outlook
On Wed, Mar 2, 2016 at 4:16 PM -0800, "Andrew Wang"
wrote:
Hi all,
I wanted to ask a release-related question. Right now, the RC tarball we
vote on is
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
not operating in
> > that manner. So, that brings us to today. At a minimum, the board is
> > expecting that we identify a way to keep release references immutable.
> >
> >
> > Thoughts, comments, flames?
> >
> > --David
>
>
> I don't know
Sangjin, Steve and others:
just curious if you guys figured out a way to address/workaround this
hurdle - not being able to delete or force push. Should we reach out to
INFRA again?
On Thu, Nov 12, 2015 at 10:21 AM, Allen Wittenauer wrote:
>
>
>
>
> > On Nov 12, 2015, at 10:14 AM, Sangjin Lee
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
Hi folks,
Recently, Infra disabled force-pushes (and non-fast-forward pushes) to all
branches to avoid accidental overwrites or deletions.
I propose we reach out to Infra and ask for an exemption since our workflow
for feature branches involves deletions and force-pushes.
We should likely wait f
Nice. Thanks for driving this, Zhe.
On Mon, Nov 9, 2015 at 3:27 PM, Zhe Zhang wrote:
> Hi,
>
> Per our earlier discussion on the "Github integration for Hadoop" thread, I
> surveyed HBase, Flume, and HTrace about their interest on Gerrit. The
> feedbacks have been positive:
>
> HBase:
>
> http:/
Owen: Thanks for putting the documentation together. I think I understand
the proposal better now.
I agree that reviewing on github is easier than having to download the
patch, apply locally, and for reviews copy-paste code to the JIRA. This, we
get from RB or any other review tool as well.
The c
On Tue, Oct 27, 2015 at 7:44 PM, Allen Wittenauer wrote:
>
> Today I discovered that an old, old code change (circa 2012)
> caused certain maven modules to be skipped during the precommit testing.
> That code had been carried forward through all the rewrites, bug fixes,
> etc, over the ye
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
[
https://issues.apache.org/jira/browse/HADOOP-12451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla reopened HADOOP-12451:
---
The committed patch avoids HADOOP_HOME is not overwritten.
In addition to this, HADOOP
Karthik Kambatla created HADOOP-12456:
-
Summary: Verify setting HADOOP_HOME explicitly works
Key: HADOOP-12456
URL: https://issues.apache.org/jira/browse/HADOOP-12456
Project: Hadoop Common
Karthik Kambatla created HADOOP-12451:
-
Summary: One should be able to set HADOOP_HOME outside as well
Key: HADOOP-12451
URL: https://issues.apache.org/jira/browse/HADOOP-12451
Project: Hadoop
+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
+1
Thanks for driving this, Andrew.
On Mon, Aug 24, 2015 at 11:00 AM, Vinayakumar B
wrote:
> +1,
>
> -Vinay
> On Aug 24, 2015 11:29 PM, "Colin P. McCabe" wrote:
>
> > +1
> >
> > cheers,
> > Colin
> >
> > On Mon, Aug 24, 2015 at 10:04 AM, Steve Loughran >
> > wrote:
> > > +1 (binding)
> > >
>
Absolutely.
On Mon, Aug 17, 2015 at 5:04 PM, Elliott Clark wrote:
> Nate (nkedel) and I have been working on IPv6 on Hadoop and HBase lately.
> We're getting somewhere but there are a lot of different places that make
> assumptions about network. That means there will be a good deal of follow
>
I prefer Proposal #1 as well. Squashing some of the commits seems a major
improvement over our previous model of a single commit for the entire
branch.
On Tue, Aug 11, 2015 at 2:19 PM, Andrew Wang
wrote:
> Hi all,
>
> We are currently working on a pretty substantial new feature in a branch
> ove
On Fri, Jul 17, 2015 at 6:04 AM, Steve Loughran
wrote:
>
> > On 16 Jul 2015, at 15:56, Karthik Kambatla wrote:
> >
> > On Thu, Jul 16, 2015 at 10:42 AM, Sean Busbey
> wrote:
> >
> >> On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla
> >> w
On Thu, Jul 16, 2015 at 10:42 AM, Sean Busbey wrote:
> On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla
> wrote:
>
> > On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran
> > wrote:
> >
> >
> > > -any change to the signature of an API, including excep
HADOOP-11710 in there, as an example.
>
> 6. And of course, any security issue patch should go in.
>
> Overall then: the expectation should be that patches won't go in by
> default, unless viewed as critical. We have to be ruthless, and people
> shouldn't commit things without getting approval from others.
>
> -Steve
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
se community.
>
> On Wed, Jul 15, 2015 at 3:49 PM, Karthik Kambatla
> wrote:
>
> > As I proposed in the other thread, how about we adopting the following
> > model:
> >
> > x.y.1 releases have all Blocker, Critical, Major bug fixes applied to the
> > next mi
of your PMC members mentioned that with continued work on
> >> the
> >>> 2.7 line y'all weren't planning any additional releases of the earlier
> >>> minor versions[6].
> >>>
> >>> The HBase commun
s that Hadoop pick up making bug-fix-only
> > patch
> > > releases again on a regular schedule[7]. Preferably on the 2.6 line and
> > > preferably monthly. We realize that given the time gap since 2.6.0 it
> > will
> > > likely take a big to get 2.6.1 together, but after that it should take
> > much
> > > less effort to continue.
> > >
> > > [1]: http://hbase.apache.org/book.html#hadoop
> > > [2]: http://s.apache.org/ReP
> > > [3]: HBASE-13339
> > > [4]: HADOOP-11674 and HADOOP-11710
> > > [5]: http://hadoop.apache.org/releases.html
> > > [6]: http://s.apache.org/MTY
> > > [7]: http://s.apache.org/ViP
> > >
> > > --
> > > Sean
> >
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
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
o share the work with the community. If we can cherry-pick bug
> >>>> fix
> >>>> patches and have more maintenance releases, it'd be very happy not
> only
> >>>> for
> >>>> users but also for developers who work very hard for stabilizing their
> >>>> own
> >>>> branches.
> >>>>
> >>>> To have more maintenance releases, I propose two changes:
> >>>>
> >>>> * Major/Minor/Trivial bug fixes can be cherry-picked
> >>>> * (Roughly) Monthly maintenance release
> >>>>
> >>>> I would like to start the work from branch-2.6. If the change will be
> >>>> accepted by the community, I'm willing to work for the maintenance,
> as a
> >>>> release manager.
> >>>>
> >>>> Best regards,
> >>>> Akira
> >>>>
> >>>
> >
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
ork very hard for stabilizing their
> own
> > branches.
> >
> > To have more maintenance releases, I propose two changes:
> >
> > * Major/Minor/Trivial bug fixes can be cherry-picked
> > * (Roughly) Monthly maintenance release
> >
> > I would l
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
gt;>>>> From: Allen Wittenauer [a...@altiscale.com]
> >>>>>> Sent: Wednesday, April 15, 2015 12:45 AM
> >>>>>> To: common-dev@hadoop.apache.org
> >>>>>> Cc: hdfs-...@hadoop.apache.org; yarn-...@hadoop.apache.org;
> mapreduce-...@hadoop
> 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
IRA. But you can always examine git
> > log.
> >
> > Colin
> >
> > On Tue, Apr 7, 2015 at 3:51 PM, Allen Wittenauer
> wrote:
> >>
> >> For those wondering, YARN-2429 is the wrong JIRA for that commit.
> Simple typo, but deadly if one is using to use the git log to determine
> what’s actually committed...
> >>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
mount of Hadoop 2.x release data into trunk so that the
> auto-indexer can pick it up
> c) update the HowToRelease information with, well, how to do releases
> based upon these new capabilities
>
There is a create-release script that likely needs updating.
>
>
> Thanks!
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
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
Karthik Kambatla created HADOOP-11779:
-
Summary: Fix pre-commit builds to execute the right set of tests
Key: HADOOP-11779
URL: https://issues.apache.org/jira/browse/HADOOP-11779
Project: Hadoop
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
get version. These, while perhaps not revolutionary, are still
> incompatible, and require a major version bump.
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
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
[
https://issues.apache.org/jira/browse/HADOOP-10584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla reopened HADOOP-10584:
---
Reopening to investigate it more. If anyone wants to pick this up, they are
more than
>
> 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?
&
review patches you are interested in. Your
> > comments will help committers to review and merge them.
> > (As you can see, the above comments don't have any enforcement.)
> >
> > Regards,
> > Akira
> >
> >
> > On 2/4/15 13:52, Karthik Kambatla wrote
a
> future
> >>>>>> piece of technology from magically fixing it?
> >>>>>>
> >>>>>> For clearing the backlog, I don't see any solution other than
> "people
> >>>>>> put in time". I know its an obligation for committers to do this,
> but I
> >>>>>> also know how little time most of us have to do things other than
> deal
> >>>>>> with our own tests failing. As a result, things that aren't viewed
> as
> >>>>>> critical get neglected. Shell, build, object stores, cruft cleanup,
> etc,
> >>>>>> I think people that care about these areas are going to have to get
> >>>>>> together and sync up. For some of the stuff it may be quite fast
> ‹people
> >>>>>> may not have noticed, but a few of us have brought the build
> >>>>>> dependencies forward fairly fast recently, with a goal of Hadoop
> >>>>>> branch-2/trunk being compatible with recent Guava versions and java
> 8.
> >>>>>>
> >>>>>> I've been doing some S3/object store work the last couple of
> weekends;
> >>>>>> that's slow as test runs take 30+ minutes against the far end, test
> runs
> >>>>>> jenkins doesn't do. If anyone else wants to look at the fs/s3 and
> >>>>>> fs/swift queue their input is welcome.
> >>>>>>
> >>>>>> And of course AW went through the entire backlog of shell stuff & a
> lot
> >>>>>> of the not-in-branch-2 features.
> >>>>>>
> >>>>>> So where now? What is a strategy to deal with all those things in
> the
> >>>>>> queue?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
Karthik Kambatla created HADOOP-11492:
-
Summary: Bump up curator version to 2.7.1
Key: HADOOP-11492
URL: https://issues.apache.org/jira/browse/HADOOP-11492
Project: Hadoop Common
Issue
;>> classes are marked as "Evolving". These really haven't changed much
> in
> >>>> the
> >>>>> last few years, so I was wondering if it is reasonable to mark them
> as
> >>>>> stable?
> >>>>>
> >>>>> -Abe
> >>>>>
> >>>>
> >>
> >>
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is 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
adoop-annotations/src/main/java/org/apache/hadoop/classification/InterfaceAudience.java
> > > )
> > > classes are marked as "Evolving". These really haven't changed much in
> > the
> > > last few years, so I was wondering if it is reasonable to mark them as
> > > stable?
> > >
> > > -Abe
> > >
> >
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
[
https://issues.apache.org/jira/browse/HADOOP-11340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved HADOOP-11340.
---
Resolution: Fixed
Sorry for the delay on this - subversion was down at the time and
[
https://issues.apache.org/jira/browse/HADOOP-10584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved HADOOP-10584.
---
Resolution: Cannot Reproduce
After posting the patch, I had tried to validate but
Karthik Kambatla created HADOOP-11447:
-
Summary: Add a more meaningful toString method to SampleStat and
MutableStat
Key: HADOOP-11447
URL: https://issues.apache.org/jira/browse/HADOOP-11447
[
https://issues.apache.org/jira/browse/HADOOP-11213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved HADOOP-11213.
---
Resolution: Fixed
Fix Version/s: 2.7.0
Hadoop Flags: Reviewed
Thanks
1 - 100 of 296 matches
Mail list logo
