Re: Disable some of the Hudson integration comments on JIRA
> On 26 Nov 2015, at 01:41, Andrew Wang wrote: > > Hi all, > > Right now we get something like 7 comments from Hudson whenever a change is > committed. Would anyone object if I turned off 6 of them? We have > variations like: > > Hadoop-trunk-Commit > Hadoop-Hdfs-trunk-Java8 > Hadoop-Yarn-trunk > ...etc > > I propose leaving notifications on for just Hadoop-trunk-Commit. +1 I'd also like to understand why those changes are always tagged as FAILED
Re: Disable some of the Hudson integration comments on JIRA
Looking at a few Hadoop-trunk-Commit builds, I saw 'Some Enforcer rules have failed.' Below was from build #8895 : [WARNING] Dependency convergence error for org.apache.hadoop:hadoop-auth:3.0.0-SNAPSHOT paths to dependency are: +-org.apache.hadoop:hadoop-common:3.0.0-SNAPSHOT +-org.apache.hadoop:hadoop-auth:3.0.0-SNAPSHOT and +-org.apache.hadoop:hadoop-common:3.0.0-SNAPSHOT +-org.apache.hadoop:hadoop-auth:3.0.0-20151126.050629-7794 [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence failed with message: Failed while enforcing releasability the error(s) are [ Dependency convergence error for org.apache.hadoop:hadoop-auth:3.0.0-SNAPSHOT paths to dependency are: +-org.apache.hadoop:hadoop-common:3.0.0-SNAPSHOT +-org.apache.hadoop:hadoop-auth:3.0.0-SNAPSHOT and +-org.apache.hadoop:hadoop-common:3.0.0-SNAPSHOT +-org.apache.hadoop:hadoop-auth:3.0.0-20151126.050629-7794 FYI On Thu, Nov 26, 2015 at 2:46 AM, Steve Loughran wrote: > > > On 26 Nov 2015, at 01:41, Andrew Wang wrote: > > > > Hi all, > > > > Right now we get something like 7 comments from Hudson whenever a change > is > > committed. Would anyone object if I turned off 6 of them? We have > > variations like: > > > > Hadoop-trunk-Commit > > Hadoop-Hdfs-trunk-Java8 > > Hadoop-Yarn-trunk > > ...etc > > > > I propose leaving notifications on for just Hadoop-trunk-Commit. > +1 > > I'd also like to understand why those changes are always tagged as FAILED >
[jira] [Created] (HADOOP-12604) Exception may be swallowed in KMSClientProvider
Yongjun Zhang created HADOOP-12604:
--
Summary: Exception may be swallowed in KMSClientProvider
Key: HADOOP-12604
URL: https://issues.apache.org/jira/browse/HADOOP-12604
Project: Hadoop Common
Issue Type: Bug
Components: kms
Reporter: Yongjun Zhang
Assignee: Yongjun Zhang
In KMSClientProvider# createConnection
{code}
try {
is = conn.getInputStream();
ret = mapper.readValue(is, klass);
} catch (IOException ex) {
if (is != null) {
is.close(); <== close may throw exception
}
throw ex;
} finally {
if (is != null) {
is.close();
}
}
}
{code}
{{ex}} may be swallowed when {{close}} highlighted in the code throws
exception. Thanks [~qwertymaniac] for pointing this out.
BTW, I think we should be able to consolidate the two {{is.close()}} in the
above code, so we don't close the same stream twice. The one in the {{finally
block}} may be called after an exception is thrown or not, and it may throw
exception too, we need to be careful not to swallow exception here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Disable some of the Hudson integration comments on JIRA
> On Nov 25, 2015, at 5:41 PM, Andrew Wang wrote: > > Hi all, > > Right now we get something like 7 comments from Hudson whenever a change is > committed. Would anyone object if I turned off 6 of them? We have > variations like: > > Hadoop-trunk-Commit > Hadoop-Hdfs-trunk-Java8 > Hadoop-Yarn-trunk > ...etc > > I propose leaving notifications on for just Hadoop-trunk-Commit. > This will give false positives since that job does a -DskipTests.
[GitHub] hadoop pull request: HADOOP-12321
GitHub user sunilgovind opened a pull request: https://github.com/apache/hadoop/pull/59 HADOOP-12321 Rebasing as per latest trunk, This is an aggregated patch with all changes together. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sunilgovind/hadoop trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/hadoop/pull/59.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #59 commit 05fd3a01ad6a182b1e0a7612d034f14a1808b4a4 Author: Sunil G Date: 2015-11-26T18:31:26Z HADOOP-12321 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [VOTE] Release Apache Hadoop 2.7.2 RC0
On Wed, Nov 25, 2015 at 01:51PM, Steve Loughran wrote: > > > On 25 Nov 2015, at 02:48, Konstantin Boudnik wrote: > > > > Vinod, hopefully it isn't too late for a quick fix to be included into 2.7.2 > > (sorry for jumping too late on this train). The JIRA in question is > > HADOOP-12415 and I have committed it to trunk and branch-2 already. > > > > Please let me know if this is still Ok to add into 2.7.2 as it seems to be > > going through a respin. Thanks in advance, > > > > Cos > > > > > can you hold it off until 2.7.3? 2.7.2 was tested and we shoudn't be making > more changes now, even if its just to the POMs It's up to you guys, the fix is small but pretty critical IMO. The change in question is literally breaking the build from the get go. In Bigtop we had to patch 2.7.1 so we at least can build it into the stack. For the users using official release tarball it won't simply work unless they are going to patch it themselves. Cos signature.asc Description: Digital signature
Re: [DISCUSS] Release numbering for stable 2.8 and beyond
On Mon, Apr 27, 2015 at 10:45AM, Andrew Wang wrote:
> I think Karthik correctly identified the two reasons we might want to
> denote a release as "unstable":
>
> a) Compatibility. Whether we have freedom to break compatibility before the
> final release, i.e. what "alpha" typically means.
Breaking compatibility within minor releases is a very novel idea, introduced
to the world by Scala, if I am not mistaken. In general though, it is a pretty
bad practice to have 2.8.0 be incompatible with 2.8.1 - this isn't what
normally is expected from a subminor update.
> b) Quality. As Konst says, a release can be allowed to break compatibility
> ("alpha") but itself still be a high quality release.
I don't think Konst has advocated to make subminors incopatible ;)
As for the original question, I'd really go with a normal versioning and
just documenting any stability concerns.
Cos
> We could try and separate out these two concerns when it comes to
> versioning, but I think in reality users only care about prod vs. non-prod,
> which is why many other projects (Linux, HBase, etc) just have two release
> lines: "stable" (compatible/good-quality) vs. "unstable"
> (unknown-compatible/unknown-quality).
>
> To this end, I don't mind what we choose, as long as the difference between
> stable and unstable is denoted by the version number. I don't like the idea
> of tagging a release as good after the fact (1). The other projects we've
> used as examples make strong statements about their stable release lines,
> and we should too. Our downstreams and end users will appreciate clarity
> from the version number.
>
> Best,
> Andrew
>
> On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah wrote:
>
> > There are a couple of different approaches we could take.
> >
> > How about publishing/releasing bits such as “2.8.0-RC0”. Downstream
> > projects can depend on these and use them normally similar to the approach
> > that they would have taken with release 2.8.0 or 2.8.0-alpha. After some
> > baking ( or more RC suffixed releases), at some point, a proper 2.8.0
> > release could be made? The RC tag clearly indicates to downstream layers
> > that things will be in flux slightly. Trying to distinguish
> > incompatibilities between 2.8.0 and 2.8.1/2.8.2 ( just because 2.8.0 was
> > tagged alpha in documentation ) are likely to be a nightmare to deal with
> > especially for new features introduced in the 2.8 release ( which might get
> > changed slightly based on usage feedback ).
> >
> > Furthermore, considering the release history of hadoop, the likelihood
> > that 2.9.0 will show up before 2.8.2 seems to be very high.
> >
> > With respect to the proposed choice (1), I thought that HBase applied a
> > different approach. The odd-number releases were always unstable and the
> > even number releases were the stable ones. This “could" make things a bit
> > more clear for downstream users without needing to resort to modified
> > versioned numbers ( with alpha/beta tags ) or requiring users to go look up
> > the website to find out which particular version of 2.8.x was the first
> > stable release.
> >
> > thanks
> > — Hitesh
> >
> >
> >
> >
> >
> > On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> > vino...@hortonworks.com> wrote:
> >
> > > Forking the thread.
> > >
> > > In the previous 2.7.1 thread [1], there were enough yays to my proposal
> > to wait for a bug-fix release or two before calling a 2.x release stable.
> > There were some concerns about the naming.
> > >
> > > We have two options, taking 2.8 as an example
> > > (1) Release 2.8.0, call it as an alpha in documentation and release
> > notes, wait for a 2.8.1/2.8.2 reasonably stable enough to be called as the
> > first stable release of 2.8.
> > > (2) Release 2.8.0-alpha, 2.8.0-beta etc before culminating in a 2.8.0
> > stable release.
> > >
> > > (1) is what I preferred first up. This is what HBase used to do, and far
> > beyond, in the linux kernel releases. It helps in scenarios where we are
> > forced to downgrade a release, say due to major issues. We can simply
> > announce it as not stable retroactively, change the pointers on our website
> > and move on.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > +Vinod
> > >
> > > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> > >
> > > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vino...@hortonworks.com> wrote:
> > >
> > >>
> > >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >>
> > >> Re 2.7.0, I just forgot about the naming initially though I was clear
> > in the discussion/voting. I so had to end up calling it alpha outside of
> > the release artifact naming.
> > >>
> > >> Thanks
> > >> +Vinod
> > >>
> > >> On Apr 21, 2015, at 4:26 PM, Andrew Wang
> > wrote:
> > >>
> > >>> 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
Re: [DISCUSS] Looking to a 2.8.0 release
> On 25 Nov 2015, at 22:01, Vinod Kumar Vavilapalli wrote: > > Tx for your comments, Andrew! > > I did talk about it in a few discussions in the past related to this but yes, > we never codified the feature-level alpha/beta tags. Part of the reason why I > never pushed for such a codification is that (a) it is a subjective decision > that the feature contributors usually have the best say on and (2) voting on > the alpha-ness / beta-ness may not be a productive exercise in non-trivial > number of cases (as I have seen with the release-level tags, some users think > an alpha release is of production quality enough for _their_ use-cases). > > That said, I agree about noting down our general recommendations on what an > alpha feature means, what a beta feature means etc. Let me file a JIRA for > this. maybe discuss having a list @ release time. As an example, s3 and encryption at rest shipped in beta stage... what's in 2.8 that "we don't yet trust ourselves?". Me, I'd put erasure coding in there just because I've no familiarity with it > > The second point you made is absolutely true. Atleast on YARN / MR side, I > usually end up traversing (some if not all of) alpha features and making sure > the corresponding APIs are explicitly marked private or public unstable / > evolving. I do think that there is a lot of value in us getting more > systematic with this - how about we do this for the feature list of 2.8 and > evolve the process? > > In general, may be we could have a list of ‘check-list’ JIRAs that we always > address before every release. Few things already come to my mind: > - Mark which features are alpha / beta and make sure the corresponding APIs, > public interfaces reflect the state + have people add JIRAs for the next version to actually mark things as stable/out of beta
