Re: Apache Hadoop qbt Report: branch2+JDK7 on Linux/x86

]. -C [1]: https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/ On Tue, May 15, 2018 at 10:27 AM, Allen Wittenauer <a...@effectivemachines.com> wrote: > >> On May 15, 2018, at 10:16 AM, Chris Douglas <cdoug...@apache.org> wrote: >> >> They've been

Re: Apache Hadoop qbt Report: branch2+JDK7 on Linux/x86

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. >

Re: [RESULT][VOTE] Merge HDDS (HDFS-7240) *code* into trunk

merge” workflows. >> Ozone had followed git merge workflow, which merged trunk at a regular >> frequency into ozone, and then ozone was merged back. >> >> Here is the mail that we followed for the merge process. >> https://lists.apache.org/thread.html/43cd65c6b6c3c0e

Re: [RESULT][VOTE] Merge HDDS (HDFS-7240) *code* into trunk

This really made a mess of trunk. Periodically merging trunk into the HDFS-7240 branch, then merging the whole thing back, created a tangle of references that's very difficult to work with (look at the output of git log --graph). I'm not sure it's even possible to fix this, but this is why

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

later. -C > Best, > Andrew > > On Mar 22, 2018 9:51 AM, "Chris Douglas" <cdoug...@apache.org> wrote: > > +1 (binding) > > This compromise seems to address most of the concerns raised during > the discussion. Thanks for proposing and driving this, Owe

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

+1 (binding) This compromise seems to address most of the concerns raised during the discussion. Thanks for proposing and driving this, Owen. On Thu, Mar 22, 2018 at 9:30 AM, Andrew Wang wrote: > In Owen's proposal, it says to delete the module from the release branch.

Re: Apache Hadoop qbt Report: trunk+JDK8 on Windows/x64

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

Re: [EVENT] HDFS Bug Bash: March 12

gt; per-meetup-charge issue, 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 <cdoug...@apache.org> wrote: > > Found a meetup alterna

Re: [EVENT] HDFS Bug Bash: March 12

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 <cdoug...@apache.org> wrote: > On Fri, Mar 9, 2018 at 7:52 PM, 俊平堵 <junping...@apache.org> wrote: >>

Re: [EVENT] HDFS Bug Bash: March 12

in the project. -C [1]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75965105 > 2018-03-05 16:03 GMT-08:00 Chris Douglas <cdoug...@apache.org>: > >> [Cross-posting, as this affects the rest of the project] >> >> Hey folks- >> >>

Re: [EVENT] HDFS Bug Bash: March 12

ng else I > can help here. > > Thanks, > > Junping > > 2018-03-05 16:03 GMT-08:00 Chris Douglas <cdoug...@apache.org>: > >> [Cross-posting, as this affects the rest of the project] >> >> Hey folks- >> >> As discussed last month [1],

Re: [VOTE] Merging branch HDFS-8707 (native HDFS client) to trunk

+1 (binding) -C On Thu, Mar 8, 2018 at 9:31 AM, Jim Clampffer wrote: > Hi Everyone, > > The feedback was generally positive on the discussion thread [1] so I'd > like to start a formal vote for merging HDFS-8707 (libhdfs++) into trunk. > The vote will be open for 7

Re: [EVENT] HDFS Bug Bash: March 12

05 On Tue, Mar 6, 2018 at 7:48 PM, Chris Douglas <cdoug...@apache.org> 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 > > &g

Re: [EVENT] HDFS Bug Bash: March 12

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 <cdoug...@apache.org> wrote: > [Cross-posting, as this affects

[EVENT] HDFS Bug Bash: March 12

[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

[jira] [Reopened] (HDFS-13216) HDFS

[ https://issues.apache.org/jira/browse/HDFS-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas reopened HDFS-13216: -- > HDFS > > > Key: HDFS-13216 > URL: https://is

[jira] [Resolved] (HDFS-13216) HDFS

[ https://issues.apache.org/jira/browse/HDFS-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas resolved HDFS-13216. -- Resolution: Invalid > HDFS > > > Key: HDFS-13216 >

Re: [DISCUSS] Merging HDFS-8707 (C++ HDFS client) to trunk

erasure >> coded file? >> 3. Is there any building/testing mechanism to enforce the consistency >> between the c++ part and Java part? >> 4. I thought the public header and lib should be exported when building >> the distribution package, otherwise hard to use the new C api.

Re: [DISCUSS] Merging HDFS-8707 (C++ HDFS client) to trunk

+1 Let's get this done. We've had many false starts on a native HDFS client. This is a good base to build on. -C On Wed, Feb 28, 2018 at 9:55 AM, Jim Clampffer wrote: > Hi everyone, > > I'd like to start a thread to discuss merging the HDFS-8707 aka libhdfs++ > into

Re: [DISCUSS] Meetup for HDFS tests and build infra

Correction: 3/12 or 3/13, as in March 12 or 13th. -C On Tue, Feb 20, 2018 at 3:59 PM, Chris Douglas <cdoug...@apache.org> wrote: > Looking at the poll [1], it looks like 12/12 or 12/13 would be the > best day to do this. If you haven't posted your availability and would > like

Re: [DISCUSS] Meetup for HDFS tests and build infra

in-person. -C [1]: https://doodle.com/poll/r22znitzae9apfbf On Fri, Feb 9, 2018 at 1:45 PM, Chris Douglas <cdoug...@apache.org> wrote: > On Thu, Feb 8, 2018 at 5:47 PM, 郑锴(铁杰) <zhengkai...@alibaba-inc.com> wrote: >>>>I'm looking at you, TestDFSStripedOutputStreamWithFailure

Re: [DISCUSS] Meetup for HDFS tests and build infra

ly help and be appreciated. > > Regards, > Kai > > ---------- > 发件人：Chris Douglas <cdoug...@apache.org> > 发送时间：2018年2月8日(星期四) 08:39 > 收件人：Hdfs-dev <hdfs-dev@hadoop.apache.org> > 主　题：Re: [DISCUSS] Meetup for HDF

Re: [DISCUSS] Meetup for HDFS tests and build infra

Created a poll [1] to inform scheduling. -C [1]: https://doodle.com/poll/r22znitzae9apfbf On Tue, Feb 6, 2018 at 3:09 PM, Chris Douglas <cdoug...@apache.org> wrote: > The HDFS build is not healthy. Many of the unit tests aren't actually > run in Jenkins due to resource exhaustion,

[DISCUSS] Meetup for HDFS tests and build infra

The HDFS build is not healthy. Many of the unit tests aren't actually run in Jenkins due to resource exhaustion, haven't been updated since build/test/data was the test temp dir, or are chronically unstable (I'm looking at you, TestDFSStripedOutputStreamWithFailure). The situation has deteriorated

Re: Apache Hadoop 3.0.1 Release plan

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

Re: [VOTE] Merge YARN-6592 feature branch to trunk

+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

[jira] [Resolved] (HDFS-12970) HdfsFileStatus#getPath returning null.

[ https://issues.apache.org/jira/browse/HDFS-12970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas resolved HDFS-12970. -- Resolution: Invalid > HdfsFileStatus#getPath returning n

[jira] [Created] (HDFS-12944) Update NOTICE for AssertJ dependency

Chris Douglas created HDFS-12944: Summary: Update NOTICE for AssertJ dependency Key: HDFS-12944 URL: https://issues.apache.org/jira/browse/HDFS-12944 Project: Hadoop HDFS Issue Type: Task

Re: [VOTE] Merge HDFS-9806 to trunk

+1 to close it out. With 6 +1 votes (5 binding) this passes. Thanks everyone, particularly Sean and Inigo for trying it out. We'll merge this soon. -C On Fri, Dec 8, 2017 at 3:44 PM, Chris Douglas <cdoug...@apache.org> wrote: > Discussion thread: https://s.apache.org/kxT1 >

[jira] [Resolved] (HDFS-12903) [READ] Fix closing streams in ImageWriter

[ https://issues.apache.org/jira/browse/HDFS-12903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas resolved HDFS-12903. -- Resolution: Fixed > [READ] Fix closing streams in ImageWri

[jira] [Reopened] (HDFS-12903) [READ] Fix closing streams in ImageWriter

[ https://issues.apache.org/jira/browse/HDFS-12903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas reopened HDFS-12903: -- > [READ] Fix closing streams in ImageWri

[jira] [Created] (HDFS-12926) open(PathHandle) contract test should be exhaustive for default options

Chris Douglas created HDFS-12926: Summary: open(PathHandle) contract test should be exhaustive for default options Key: HDFS-12926 URL: https://issues.apache.org/jira/browse/HDFS-12926 Project

[VOTE] Merge HDFS-9806 to trunk

Discussion thread: https://s.apache.org/kxT1 We're down to the last few issues and are preparing the branch to merge to trunk. We'll post merge patches to HDFS-9806 [1]. Minor, "cleanup" tasks (checkstyle, findbugs, naming, etc.) will be tracked in HDFS-12712 [2]. We've tried to ensure that when

[jira] [Resolved] (HDFS-10262) Change HdfsFileStatus::fileId to an opaque identifier

[ https://issues.apache.org/jira/browse/HDFS-10262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas resolved HDFS-10262. -- Resolution: Duplicate Fixed in HDFS-7878 > Change HdfsFileStatus::fileId to an opa

[jira] [Created] (HDFS-12885) Add visibility/stability annotations

Chris Douglas created HDFS-12885: Summary: Add visibility/stability annotations Key: HDFS-12885 URL: https://issues.apache.org/jira/browse/HDFS-12885 Project: Hadoop HDFS Issue Type: Sub

[DISCUSS] Merge HDFS-9806 to trunk

Hey hdfs-dev@- The HDFS-9806 dev branch is getting ready to merge to trunk. This branch adds a new storage type (PROVIDED) to support reading remote data as HDFS blocks. Design documentation and discussion are available on JIRA [1]. Over the next week or so, we'll work through the remaining

[jira] [Created] (HDFS-12882) Support full open(PathHandle) contract in HDFS

Chris Douglas created HDFS-12882: Summary: Support full open(PathHandle) contract in HDFS Key: HDFS-12882 URL: https://issues.apache.org/jira/browse/HDFS-12882 Project: Hadoop HDFS Issue

[jira] [Reopened] (HDFS-11576) Block recovery will fail indefinitely if recovery time > heartbeat interval

[ https://issues.apache.org/jira/browse/HDFS-11576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas reopened HDFS-11576: -- Reopening for branch-2 > Block recovery will fail indefinitely if recovery time > hea

[jira] [Reopened] (HDFS-11576) Block recovery will fail indefinitely if recovery time > heartbeat interval

[ https://issues.apache.org/jira/browse/HDFS-11576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas reopened HDFS-11576: -- Reopening because {{TestPipelinesFailover}} isn't spurious, this time. > Block recovery will f

[jira] [Created] (HDFS-12877) Add open(PathHandle) with default buffersize

Chris Douglas created HDFS-12877: Summary: Add open(PathHandle) with default buffersize Key: HDFS-12877 URL: https://issues.apache.org/jira/browse/HDFS-12877 Project: Hadoop HDFS Issue Type

[jira] [Created] (HDFS-12874) [READ] Documentation for provided storage

Chris Douglas created HDFS-12874: Summary: [READ] Documentation for provided storage Key: HDFS-12874 URL: https://issues.apache.org/jira/browse/HDFS-12874 Project: Hadoop HDFS Issue Type

[jira] [Created] (HDFS-12844) TestClientDistributedCacheManager::testDetermineCacheVisibilities assumes all parent dirs set other exec

Chris Douglas created HDFS-12844: Summary: TestClientDistributedCacheManager::testDetermineCacheVisibilities assumes all parent dirs set other exec Key: HDFS-12844 URL: https://issues.apache.org/jira/browse/HDFS

[jira] [Reopened] (HDFS-12681) Fold HdfsLocatedFileStatus into HdfsFileStatus

[ https://issues.apache.org/jira/browse/HDFS-12681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas reopened HDFS-12681: -- Reopening to revert this, and try another approach > Fold HdfsLocatedFileSta

Re: [VOTE] Release Apache Hadoop 2.9.0 (RC3)

+1 (binding) Verified source tarball. Checksum and signature match, built from source, ran some unit tests. Skimmed NOTICE/LICENSE. -C On Mon, Nov 13, 2017 at 4:10 PM, Arun Suresh wrote: > Hi Folks, > > Apache Hadoop 2.9.0 is the first release of Hadoop 2.9 line and will be

Re: [VOTE] Release Apache Hadoop 2.9.0 (RC0)

The labor required for these release formalisms is exceeding their value. Our minor releases have more bugs than our patch releases (we hope), but every consumer should understand how software versioning works. Every device I own has bugs on major OS updates. That doesn't imply that every minor

[jira] [Created] (HDFS-12729) Document special paths in HDFS

Chris Douglas created HDFS-12729: Summary: Document special paths in HDFS Key: HDFS-12729 URL: https://issues.apache.org/jira/browse/HDFS-12729 Project: Hadoop HDFS Issue Type: Task

Re: Apache Hadoop qbt Report: branch2+JDK7 on Linux/x86

Sean/Junping- Ignoring the epistemology, it's a problem. Let's figure out what's causing memory to balloon and then we can work out the appropriate remedy. Is this reproducible outside the CI environment? To Junping's point, would YETUS-561 provide more detailed information to aid debugging? -C

Re: [VOTE] Release Apache Hadoop 2.8.2 (RC1)

+1 (binding) Looked through the src distribution. Checksum, signatures match, ran some of the unit tests. Also checked the site docs; thanks for updating the Docker container security docs. Thanks, Junping. -C On Thu, Oct 19, 2017 at 5:42 PM, Junping Du wrote: > Hi folks,

[jira] [Created] (HDFS-12681) Fold HdfsLocatedFileStatus into HdfsFileStatus

Chris Douglas created HDFS-12681: Summary: Fold HdfsLocatedFileStatus into HdfsFileStatus Key: HDFS-12681 URL: https://issues.apache.org/jira/browse/HDFS-12681 Project: Hadoop HDFS Issue

Re: [VOTE] Merge Router-Based Federation (HDFS-10467) branch into trunk/branch-3

note that all the functionality is in the Router (a new >> component) so everything is isolated. >> >> In addition, no new APIs have been added and we rely fully in >> ClientProtocol. >> >> >> >> I’d like to thank the people at Microsoft (special

Re: [VOTE] Release Apache Hadoop 2.8.2 (RC0)

d that it shouldn't be enabled in secure environments. How are users supposed to make this determination without it? > Vote still continue until a real blocker comes. Soright. I remain -1. -C > ________ > From: Chris Douglas <cdoug...@apache.org> > Sent: M

Re: [VOTE] Release Apache Hadoop 2.8.2 (RC0)

-1 (binding) I don't think we should release this without YARN-6622. Since this doesn't happen often: a -1 in this case is NOT a veto. Releases are approved by majority vote of the PMC. -C On Mon, Sep 11, 2017 at 11:45 AM, Junping Du wrote: > Thanks Mikols for notifying

[jira] [Created] (HDFS-12417) Disable flaky TestDFSStripedOutputStreamWithFailure

Chris Douglas created HDFS-12417: Summary: Disable flaky TestDFSStripedOutputStreamWithFailure Key: HDFS-12417 URL: https://issues.apache.org/jira/browse/HDFS-12417 Project: Hadoop HDFS

[jira] [Reopened] (HDFS-12349) Improve log message when it could not alloc enough blocks for EC

[ https://issues.apache.org/jira/browse/HDFS-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas reopened HDFS-12349: -- > Improve log message when it could not alloc enough blocks for

[jira] [Created] (HDFS-12410) Ignore unknown StorageTypes

Chris Douglas created HDFS-12410: Summary: Ignore unknown StorageTypes Key: HDFS-12410 URL: https://issues.apache.org/jira/browse/HDFS-12410 Project: Hadoop HDFS Issue Type: Task

Re: [DISCUSS] Merge HDFS-10467 to (Router-based federation) trunk

unimplemented methods. >- There is some argument about naming the feature as “Router-based > federation” but I’m open for better names. > > > > *Credits*: > > I’d like to thank the people at Microsoft (specially, Jason, Ricardo, > Chris, Subru, Jakob, Carlo and Giovanni), T

Re: [VOTE] Release Apache Hadoop 2.7.4 (RC0)

+1 (binding) Looked through the src tarball. Checksum and signature match, skimmed NOTICE/LICENSE, ran some unit tests. -C On Sat, Jul 29, 2017 at 4:29 PM, Konstantin Shvachko wrote: > Hi everybody, > > Here is the next release of Apache Hadoop 2.7 line. The previous

[jira] [Created] (HDFS-12250) Reduce usage of FsPermissionExtension in HDFS unit tests

Chris Douglas created HDFS-12250: Summary: Reduce usage of FsPermissionExtension in HDFS unit tests Key: HDFS-12250 URL: https://issues.apache.org/jira/browse/HDFS-12250 Project: Hadoop HDFS

Re: [VOTE] Release Apache Hadoop 2.7.4 (RC0)

gt; On Mon, Jul 31, 2017 at 3:56 PM Chris Douglas <cdoug...@apache.org> wrote: > >> On Mon, Jul 31, 2017 at 3:02 PM, Konstantin Shvachko >> <shv.had...@gmail.com> wrote: >> > For the packaging, here is the exact phrasing from the sited >> release-policy &

Re: [VOTE] Release Apache Hadoop 2.7.4 (RC0)

On Mon, Jul 31, 2017 at 3:02 PM, Konstantin Shvachko wrote: > For the packaging, here is the exact phrasing from the sited release-policy > document relevant to binaries: > "As a convenience to users that might not have the appropriate tools to > build a compiled version of

Re: Can we update protobuf's version on trunk?

On Wed, Mar 29, 2017 at 4:59 PM, Stack wrote: >> The former; an intermediate handler decoding, [modifying,] and >> encoding the record without losing unknown fields. >> > > I did not try this. Did you? Otherwise I can. Yeah, I did. Same format. -C >> This looks fine. -C >> >>

Re: Can we update protobuf's version on trunk?

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

[jira] [Resolved] (HDFS-10640) Modify LOG statements to use sl4j templates.

[ https://issues.apache.org/jira/browse/HDFS-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas resolved HDFS-10640. -- Resolution: Later Closing this, given attention to solving this across the project in HADOOP

Re: Can we update protobuf's version on trunk?

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

Re: Can we update protobuf's version on trunk?

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

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

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

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

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

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

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

Re: [VOTE] Release cadence and EOL

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

Re: [VOTE] Release cadence and EOL

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

Re: [VOTE] Merge HADOOP-13341

+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

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> 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.

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

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

[jira] [Created] (HDFS-10706) Add tool generating FSImage from external store

Chris Douglas created HDFS-10706: Summary: Add tool generating FSImage from external store Key: HDFS-10706 URL: https://issues.apache.org/jira/browse/HDFS-10706 Project: Hadoop HDFS Issue

Re: Why there are so many revert operations on trunk?

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

Re: Looking to a Hadoop 3 release

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

[jira] [Created] (HDFS-10262) Change HdfsFileStatus::fileId to an opaque identifier

Chris Douglas created HDFS-10262: Summary: Change HdfsFileStatus::fileId to an opaque identifier Key: HDFS-10262 URL: https://issues.apache.org/jira/browse/HDFS-10262 Project: Hadoop HDFS

[jira] [Resolved] (HDFS-9938) Support extensions to WebHdfsFileSystem

[ https://issues.apache.org/jira/browse/HDFS-9938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Douglas resolved HDFS-9938. - Resolution: Won't Fix Yes, thanks for opening this [~vishwajeet.dusane]. Resolving as WONTFIX

[jira] [Created] (HDFS-9806) Allow HDFS block replicas to be provided by an external storage system

Chris Douglas created HDFS-9806: --- Summary: Allow HDFS block replicas to be provided by an external storage system Key: HDFS-9806 URL: https://issues.apache.org/jira/browse/HDFS-9806 Project: Hadoop

[jira] [Created] (HDFS-9807) Add an optional StorageID to writes

Chris Douglas created HDFS-9807: --- Summary: Add an optional StorageID to writes Key: HDFS-9807 URL: https://issues.apache.org/jira/browse/HDFS-9807 Project: Hadoop HDFS Issue Type: Improvement

[jira] [Created] (HDFS-9808) Combine READ_ONLY_SHARED DatanodeStorages with the same ID

Chris Douglas created HDFS-9808: --- Summary: Combine READ_ONLY_SHARED DatanodeStorages with the same ID Key: HDFS-9808 URL: https://issues.apache.org/jira/browse/HDFS-9808 Project: Hadoop HDFS

Re: Hadoop encryption module as Apache Chimera incubator project

equirements will put more challenges >>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 targ

Re: Hadoop encryption module as Apache Chimera incubator project

om the internet. >> >>Kai Zheng's question about whether we would bundle openSSL's libraries is >>a good one. Given the high rate of new vulnerabilities discovered in >>that library, it seems like bundling would require Hadoop users and >>vendors to update ver

Re: Hadoop encryption module as Apache Chimera incubator project

a better target than a separate project. -C On Wed, Feb 3, 2016 at 1:49 AM, Chris Douglas <cdoug...@apache.org> wrote: > On Wed, Feb 3, 2016 at 12:48 AM, Gangumalla, Uma > <uma.ganguma...@intel.com> wrote: >>>Standing in the point of shared fundamental piece of code like

Re: Hadoop encryption module as Apache Chimera incubator project

As a subproject of Hadoop, Chimera could maintain its own cadence. There's also no reason why it should maintain dependencies on other parts of Hadoop, if those are separable. How is this solution inadequate? If Chimera is not successful as an independent project or stalls, Hadoop and/or Spark

Re: [DISCUSS] Looking to a 2.8.0 release

With two active sustaining branches (2.6, 2.7), what would you think of releasing trunk as 3.x instead of pushing 2.8? There are many new features (EC, Y1197, etc.), and trunk could be the source of several alpha/beta releases before we fork the 3.x line. -C On Sat, Sep 26, 2015 at 12:49 PM,

[jira] [Created] (HDFS-9020) Support hflush/hsync in WebHDFS

Chris Douglas created HDFS-9020: --- Summary: Support hflush/hsync in WebHDFS Key: HDFS-9020 URL: https://issues.apache.org/jira/browse/HDFS-9020 Project: Hadoop HDFS Issue Type: Improvement

Re: Looking to a Hadoop 3 release

On Fri, Mar 6, 2015 at 4:32 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: I'd encourage everyone to post their wish list on the Roadmap wiki that *warrants* making incompatible changes forcing us to go 3.x. This is a useful exercise, but not a prerequisite to releasing 3.0.0 as an

Re: [VOTE] Migration from subversion to git for version control

+1 -C On Fri, Aug 8, 2014 at 7:57 PM, Karthik Kambatla ka...@cloudera.com 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

Re: [VOTE] Change by-laws on release votes: 5 days instead of 7

+1 -C On Tue, Jun 24, 2014 at 1:53 AM, Arun C Murthy a...@hortonworks.com 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

Re: [VOTE] Release Apache Hadoop 2.3.0

+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 a...@hortonworks.com wrote: Folks, I've created a release candidate (rc0) for hadoop-2.3.0 that I would like to get released. The

Re: Is it me or is the new bootstrap HDFS UI HWX green? (See tip of hadoop-2.3 branch)

Stack- It's impossible to distinguish uncertainty from concern-trolling on public lists. I'm concerned that the right honorable gentleman's rash may be syphilis. What says the senate? is not innocent, even if it's sincere. Speak discreetly to your colleagues, who happen to share your aversion to

Re: [VOTE] Release Apache Hadoop 2.0.5-alpha (rc2)

+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 t...@cloudera.com wrote: +1 RC2. Verified MD5 signature, checked CHANGES.txt files, built, configured pseudo

Re: [VOTE] Release Apache Hadoop 0.23.8

+1 Checksum and signature match, ran some tests. -C On Mon, Jun 3, 2013 at 1:19 PM, Sandy Ryza sandy.r...@cloudera.com 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

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy a...@hortonworks.com 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

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

at 01:48PM, Chris Douglas wrote: On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy a...@hortonworks.com 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

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

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 a...@hortonworks.com wrote: Why not include MAPREDUCE-4211 as well rather than create one release per patch? From Cos's description

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

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 Thu, May 30, 2013 at 01:48PM, Chris Douglas

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

+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 c...@apache.org wrote: All, I have created a

Re: Heads up - 2.0.5-beta

On Thu, May 2, 2013 at 2:11 AM, Konstantin Shvachko shv.had...@gmail.com wrote: On Thu, May 2, 2013 at 12:07 AM, Chris Douglas cdoug...@apache.org 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

  1   2   >