[jira] [Created] (HADOOP-12235) hadoop-openstack junit & mockito dependencies should be "provided"

Steve Loughran created HADOOP-12235: --- Summary: hadoop-openstack junit & mockito dependencies should be "provided" Key: HADOOP-12235 URL: https://issues.apache.org/jira/browse/HADOOP-12235 Project: H

Jenkins build is back to normal : Hadoop-Common-trunk #1555

See

[jira] [Created] (HADOOP-12236) mvn site -Preleasedoc doesn't work behind proxy

Tsuyoshi Ozawa created HADOOP-12236: --- Summary: mvn site -Preleasedoc doesn't work behind proxy Key: HADOOP-12236 URL: https://issues.apache.org/jira/browse/HADOOP-12236 Project: Hadoop Common

[jira] [Created] (HADOOP-12237) releasedocmaker.py doesn't work behind a proxy

Tsuyoshi Ozawa created HADOOP-12237: --- Summary: releasedocmaker.py doesn't work behind a proxy Key: HADOOP-12237 URL: https://issues.apache.org/jira/browse/HADOOP-12237 Project: Hadoop Common

[jira] [Created] (HADOOP-12238) Passing project option to releasedocmaker.py for running mvn site -Preleasedocs

Tsuyoshi Ozawa created HADOOP-12238: --- Summary: Passing project option to releasedocmaker.py for running mvn site -Preleasedocs Key: HADOOP-12238 URL: https://issues.apache.org/jira/browse/HADOOP-12238

[jira] [Resolved] (HADOOP-12238) Passing project option to releasedocmaker.py for running mvn site -Preleasedocs

[ https://issues.apache.org/jira/browse/HADOOP-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HADOOP-12238. --- Resolution: Duplicate There's already a JIRA covering moving trunk's releasedoc supp

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Strong +1 for having a 2.6.1 release. I understand Vinod has been trying to get that effort going but it's been stalled a little bit. It would be good to rekindle that effort. Companies with big hadoop 2.x deployments (including mine) have always tried to stabilize a 2.x release by testing/collect

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

I believe there was general consensus to do more maintenance releases, as witnessed in the other thread. There have been discussions on what should go into 2.x.1, 2.x.2, etc., but I don't think we have a clear proposal. It would be nice to put that together, so committers know where all to commit

[jira] [Created] (HADOOP-12239) StorageException complaining " no lease ID" when updating FolderLastModifiedTime in WASB

Duo Xu created HADOOP-12239: --- Summary: StorageException complaining " no lease ID" when updating FolderLastModifiedTime in WASB Key: HADOOP-12239 URL: https://issues.apache.org/jira/browse/HADOOP-12239 Proj

2.7.2 release plan

Hi all, Thanks everyone for the push on 2.7.1! Branch-2.7 is now open for commits to a 2.7.2 release. JIRA also now has a 2.7.2 version for all the sub-projects. Continuing the previous 2.7.1 thread on steady maintenance releases [1], we should follow up 2.7.1 with a 2.7.2 within 4 weeks. Earli

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Why not just have the discussion here? It seems integral to the matter of having more maintenance releases on those versions. On Wed, Jul 15, 2015 at 11:39 AM, Karthik Kambatla wrote: > I believe there was general consensus to do more maintenance releases, as > witnessed in the other thread. > >

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Yeah, I started a thread while back on this one (http://markmail.org/message/sbykjn5xgnksh6wg) and had many offline discussions re 2.6.1. The biggest problem I found offline was about what bug-fixes are acceptable and what aren’t for everyone wishing to consume 2.6.1. Given the number of bug-f

Re: Planning Hadoop 2.6.1 release

Got pinged on a recent thread on this one. As I mentioned there, I had many offline discussions re 2.6.1. The biggest problem I found offline was about what bug-fixes are acceptable and what aren’t for everyone wishing to consume 2.6.1. Given the number of bug-fixes that went into 2.7.x and int

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

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 minor release. x.y.2 releases have all Blocker, Critical bug fixes applied to the next minor release. x.y.3 releases have all Blocker bug fix

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Why not just include all backwards compatible bug fixes? Alternatively, why not appoint a Release Manager for the minor release line and then allow them to arbitrate when there's disagreement about inclusion? This has worked well in the HBase community. On Wed, Jul 15, 2015 at 3:49 PM, Karthik Ka

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Every new patch potentially brings in new bugs. So, if we want to limit the kinds of potential bugs introduced in point releases, we might want to limit what gets in. Would be nice to make sure a point release is more stable than a previous point release in that line. On Wed, Jul 15, 2015 at 2:07

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

I think the bar for making the maintenance releases should be set reasonably high, and the main reason is the concern for stability/regression. Unfortunately there have been cases where a seemingly innocuous bug fix introduced regressions, small or large. And that defeats the purpose of a maintenan

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

If people are concerned about regression then just don't install new versions, or install a vendor tested stable version. Giving users choices is a good thing for stability. On Wed, Jul 15, 2015 at 2:17 PM, Sangjin Lee wrote: > I think the bar for making the maintenance releases should be set >

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

On Wed, Jul 15, 2015 at 2:07 PM, Sean Busbey wrote: > Alternatively, why not appoint a Release Manager for the minor release line > and then allow them to arbitrate when there's disagreement about inclusion? > This has worked well in the HBase community. Release managers aren't appointed in Hado

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

+1 Chris is right. ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@na

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Over on HBase, committers volunteer to be release runners for a whole release line. I wouldn't use the word 'appoint' necessarily because the arrangement is an informal communal practice, not written down anywhere as policy or codified into bylaws. If it is helpful to have a data point from anothe

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Is there anyone interested in volunteering to run a 2.6.1 release (Akira?)? You'd get some help (especially if the bar is set high and only critical bug fixes are allowed in: i.e. no features, no 'perf' fixes, no jar updates, and so on). St.Ack On Wed, Jul 15, 2015 at 3:07 PM, Chris Douglas wrot

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

I can understand these (sort of newish) questions from hbase-dev. We already have a well laid-out release-management process. If people want to learn more about how it works, please head over to http://hadoop.apache.org/bylaws.html. In terms of 2.6.1 release management, it wasn’t stuck for lack

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Inline On Wed, Jul 15, 2015 at 5:22 PM, Vinod Kumar Vavilapalli < vino...@hortonworks.com> wrote: > I can understand these (sort of newish) questions from hbase-dev. We > already have a well laid-out release-management process. If people want to > learn more about how it works, please head over t

Re: Planning Hadoop 2.6.1 release

Alright, I’d like to make progress while the issue is hot. I created a label to discuss on the candidate list of patches: https://issues.apache.org/jira/issues/?jql=labels%20%3D%202.6.1-candidate Next steps, I’ll do the fol

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

To close the loop on this one, I created a label for the candidate list of patches: https://issues.apache.org/jira/issues/?jql=labels%20%3D%202.6.1-candidate, in order to make progress while the issue is still hot. The dis

[jira] [Created] (HADOOP-12240) Fix tests requiring native library to be skipped in non-native profile

Masatake Iwasaki created HADOOP-12240: - Summary: Fix tests requiring native library to be skipped in non-native profile Key: HADOOP-12240 URL: https://issues.apache.org/jira/browse/HADOOP-12240 Pr

Re: Planning Hadoop 2.6.1 release

Thanks Vinod for creating the list! > @Akira, let’s sync up offline on how to take this forward in terms of the release process. Okay. Thanks, Akira On 7/16/15 10:24, Vinod Kumar Vavilapalli wrote: Alright, I’d like to make progress while the issue is hot. I created a label to discuss on t

Re: [Test-Patch TLP] consensus on naming

Hi Allen>    Just to be clear:  yetus is about the layer between Jenkins and the unit tests.  Many Apache communities don’t bother looking at Jenkins and it’s reporting because a) it’s extremely noisy when you’re testing literally hundreds to thousands of patches a week (plus full builds!) and b

[jira] [Created] (HADOOP-12241) Add specification of FileStatus

Masatake Iwasaki created HADOOP-12241: - Summary: Add specification of FileStatus Key: HADOOP-12241 URL: https://issues.apache.org/jira/browse/HADOOP-12241 Project: Hadoop Common Issue Typ

[jira] [Created] (HADOOP-12242) Add TOC to filesystem.md

Masatake Iwasaki created HADOOP-12242: - Summary: Add TOC to filesystem.md Key: HADOOP-12242 URL: https://issues.apache.org/jira/browse/HADOOP-12242 Project: Hadoop Common Issue Type: Sub-

Re: 2.7.2 release plan

Thanks Vinod for starting 2.7.2 release plan. > The focus obviously is to have blocker issues [2], bug-fixes and *no* > features / improvements. Can we adopt the plan as Karthik mentioned in "Additional maintenance releases for Hadoop 2.y versions" thread? That way we can include not only bloc