Re: Which newbie Jira's need work?
If you happen to know which committers tend to do a lot of code reviews in the specific area of the code covered by your patch, then tagging them in a jira comment is an effective approach. If you're unsure who to contact, then please feel free to email the appropriate project-specific *-dev list for help. I agree that our jira metadata can be messy, and that can make it challenging to find issues that really do need work. The committers have some efforts under way now to try to keep our bug tracking cleaner. One specific thing we can all do in this area is to apply the newbie label to appropriate issues, so that new contributors can run an easy jira query. Meanwhile, if there is every any doubt, please feel free to ask committers. In the case of HADOOP-10861, I think the right approach is to review the current web UI code, and if there are no occurrences of invalid HTML, then the issue can be resolved as Not a Problem. Chris Nauroth Hortonworks http://hortonworks.com/ On 4/23/15, 12:53 AM, Darrell Taylor darrell.tay...@gmail.com wrote: Hi Tsuyoshi On Wed, Apr 22, 2015 at 9:16 AM, Tsuyoshi Ozawa oz...@apache.org wrote: Hi Darrell, Thank you for having interest for contributions to Hadoop project! * How do I know if a newbie Jira is even still valid? Please ping committers whether the issue is valid when the issue looks to have been resolved already. What is the recommended way to do this? Tag them in a Jira comment? Send a message to the mailing list? * Does anybody have any suggestions for a suitable newbie ticket to pick up? One suggestion from me is to use JQL on JIRA to find issues for newbie. If you run following query, you will find fresh and open issues. project = Hadoop Common and labels = newbie and status = open ORDER BY updatedDate I have already been looking through these from a link Allen sent me, but this is what prompted my previous post. It's hard to tell if something has been done elsewhere, e.g. HADOOP-10861 Also I think one good starting point is to fix documentation, typos in code, trivial changes, or something. OK, I'll take another sweep through and see what I can find. Thanks Darrell Thanks, - Tsuyoshi On Wed, Apr 22, 2015 at 4:47 PM, Darrell Taylor darrell.tay...@gmail.com wrote: Hi All, First off I've submitted a patch for HADOOP-11813 as a starter for 10, this was an easy change and starts to get me familiar with where things are. Now I've been looking through the newbie Jira's to see what else I can do to help, but I'm struggling to see the wood for the trees, which I suspect is down to my lack of knowledge around how things hang together. I figured I'd go for some easy stuff to start with, so had a look at HADOOP-10861. Most of the html I can find under /hadoop-hdfs-project/hadoop-hdfs/src/main/webapps seems to be valid. After further digging I found HDFS-274 which appears to be a patch for the pages when they were .jsp instead of html, so does this just need closing? So essentially this boils down to two mains questions: * How do I know if a newbie Jira is even still valid? * Does anybody have any suggestions for a suitable newbie ticket to pick up? Thanks Darrell
Re: IMPORTANT: testing patches for branches
1. I really like the new patch process, especially the at-a-glance summary 2. I think being -1 on whitespace is overkill; Its just part of my git apply -p 0 -3 --verbose --whitespace=fix action. Accordingly, I won't reject patches on whitespace alone. 3. if checkstyle is complaining, how to track it down? As example, I don't see much from: https://builds.apache.org/job/PreCommit-HADOOP-Build/6167/artifact/patchprocess/checkstyle-result-diff.txt On 23 Apr 2015, at 12:21, Allen Wittenauer a...@altiscale.com wrote: On Apr 22, 2015, at 11:34 PM, Zheng, Kai kai.zh...@intel.com wrote: Hi Allen, This sounds great. Naming a patch foo-HDFS-7285.00.patch should get tested on the HDFS-7285 branch. Does it happen locally in developer's machine when running test-patch.sh, or also mean something in Hadoop Jenkins building when a JIRA becoming patch available? Thanks. Both, now that a fix has been committed last night (there was a bug in the Jenkins handling). Given a patch name or URL, Jenkins and even running locally will try a few different methods to figure out which branch to use out. Note that a branch name of ‘gitX’ where X is a valid git reference also works to force a patch to start at a particular commit. For local use, you’ll want to use a ‘spare’ copy of the source tree via the —basedir option and use the —resetrepo flag. That will enable Jenkins-like behavior and gives it permission to make modifications and effectively nuke any changes in the source tree you point it at. (Basically the opposite of the —dirty-workspace flag). If you want to force a branch (for whatever reason, including where the branch can’t be figured out), you can use the —branch option. If you don’t use —resetrepo, test-patch.sh will warn that it thinks the wrong branch is being used but will push on anyway. In any case, the result of what it thinks the branch is/should be will be in the summary output at the bottom along with the git ref that it specifically used for the test.
2.7.1 status
As we talked before [1], I am going to start the push for 2.7.1 [2]. Here are the things I am going to do, with help from others in the community - Review current 2.7.1 content to make sure only bug fixes went in - Review 2.8 to see if any important bug fixes didn't get merged into 2.7.1 - Send notes to downstream projects to see if they can pick up 2.7.0 mainly with a view of catching incompatibilities/critical issues If you feel like there is an important fix that you need in 2.7.1, please mark it so on JIRA so we can coordinate the release timeline. Also, it will be great if other community members share their testing results on 2.7.0 +, so that we can settle on a stable 2.7.1. Thanks +Vinod [1]: A 2.7.1 release to follow up 2.7.0 http://markmail.org/thread/zwzze6cqqgwq4rmw [2] JIRA filter I am using to track blockers/criticals: https://issues.apache.org/jira/issues/?filter=12331550
Re: IMPORTANT: testing patches for branches
About (3.) , a lot of the check style rules seem to be arcane/unnecessary. Please see : https://issues.apache.org/jira/browse/HADOOP-11869 On Thu, Apr 23, 2015 at 10:45 AM, Steve Loughran ste...@hortonworks.com wrote: 1. I really like the new patch process, especially the at-a-glance summary 2. I think being -1 on whitespace is overkill; Its just part of my git apply -p 0 -3 --verbose --whitespace=fix action. Accordingly, I won't reject patches on whitespace alone. 3. if checkstyle is complaining, how to track it down? As example, I don't see much from: https://builds.apache.org/job/PreCommit-HADOOP-Build/6167/artifact/patchprocess/checkstyle-result-diff.txt On 23 Apr 2015, at 12:21, Allen Wittenauer a...@altiscale.com wrote: On Apr 22, 2015, at 11:34 PM, Zheng, Kai kai.zh...@intel.com wrote: Hi Allen, This sounds great. Naming a patch foo-HDFS-7285.00.patch should get tested on the HDFS-7285 branch. Does it happen locally in developer's machine when running test-patch.sh, or also mean something in Hadoop Jenkins building when a JIRA becoming patch available? Thanks. Both, now that a fix has been committed last night (there was a bug in the Jenkins handling). Given a patch name or URL, Jenkins and even running locally will try a few different methods to figure out which branch to use out. Note that a branch name of ‘gitX’ where X is a valid git reference also works to force a patch to start at a particular commit. For local use, you’ll want to use a ‘spare’ copy of the source tree via the —basedir option and use the —resetrepo flag. That will enable Jenkins-like behavior and gives it permission to make modifications and effectively nuke any changes in the source tree you point it at. (Basically the opposite of the —dirty-workspace flag). If you want to force a branch (for whatever reason, including where the branch can’t be figured out), you can use the —branch option. If you don’t use —resetrepo, test-patch.sh will warn that it thinks the wrong branch is being used but will push on anyway. In any case, the result of what it thinks the branch is/should be will be in the summary output at the bottom along with the git ref that it specifically used for the test.
[jira] [Created] (HADOOP-11874) s3a can throw spurious IOEs on close()
Steve Loughran created HADOOP-11874: --- Summary: s3a can throw spurious IOEs on close() Key: HADOOP-11874 URL: https://issues.apache.org/jira/browse/HADOOP-11874 Project: Hadoop Common Issue Type: Bug Components: fs/s3 Affects Versions: 2.7.0 Reporter: Steve Loughran from a code review, it's clear that the issue seen in HADOOP-11851 can surface in S3a, though with HADOOP-11570, it's less likely. It will only happen on those cases when abort() isn't called. The clean close() code path needs to catch IOEs from the wrappedStream and call abort() in that situation too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HADOOP-11851) s3n to swallow IOEs on inner stream close
[ https://issues.apache.org/jira/browse/HADOOP-11851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Loughran resolved HADOOP-11851. - Resolution: Fixed Fix Version/s: 2.7.1 s3n to swallow IOEs on inner stream close - Key: HADOOP-11851 URL: https://issues.apache.org/jira/browse/HADOOP-11851 Project: Hadoop Common Issue Type: Improvement Components: fs/s3 Affects Versions: 2.6.0 Reporter: Steve Loughran Assignee: Takenori Sato Priority: Minor Fix For: 2.7.1 We've seen a situation where some work was failing from (recurrent) connection reset exceptions. Irrespective of the root cause, these were surfacing not in the read operations, but when the input stream was being closed -including during a seek() These exceptions could be caught logged warn, rather than trigger immediate failures. It shouldn't matter to the next GET whether the last stream closed prematurely, as long as the new one works -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HADOOP-11872) hadoop dfs command prints message about using yarn jar on Windows(branch-2 only)
Varun Vasudev created HADOOP-11872:
--
Summary: hadoop dfs command prints message about using yarn
jar on Windows(branch-2 only)
Key: HADOOP-11872
URL: https://issues.apache.org/jira/browse/HADOOP-11872
Project: Hadoop Common
Issue Type: Bug
Components: scripts
Reporter: Varun Vasudev
Assignee: Varun Vasudev
Priority: Minor
Using the hadoop dfs command on a branch-2 build prints a message about using
yarn jar.
{noformat}
C:\hadoop\hadoop-common-project\hadoop-common\src\main\bin hadoop.cmd dfs -ls
note: please use yarn jar to launch
YARN applications, not this command.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Which newbie Jira's need work?
Hi Tsuyoshi On Wed, Apr 22, 2015 at 9:16 AM, Tsuyoshi Ozawa oz...@apache.org wrote: Hi Darrell, Thank you for having interest for contributions to Hadoop project! * How do I know if a newbie Jira is even still valid? Please ping committers whether the issue is valid when the issue looks to have been resolved already. What is the recommended way to do this? Tag them in a Jira comment? Send a message to the mailing list? * Does anybody have any suggestions for a suitable newbie ticket to pick up? One suggestion from me is to use JQL on JIRA to find issues for newbie. If you run following query, you will find fresh and open issues. project = Hadoop Common and labels = newbie and status = open ORDER BY updatedDate I have already been looking through these from a link Allen sent me, but this is what prompted my previous post. It's hard to tell if something has been done elsewhere, e.g. HADOOP-10861 Also I think one good starting point is to fix documentation, typos in code, trivial changes, or something. OK, I'll take another sweep through and see what I can find. Thanks Darrell Thanks, - Tsuyoshi On Wed, Apr 22, 2015 at 4:47 PM, Darrell Taylor darrell.tay...@gmail.com wrote: Hi All, First off I've submitted a patch for HADOOP-11813 as a starter for 10, this was an easy change and starts to get me familiar with where things are. Now I've been looking through the newbie Jira's to see what else I can do to help, but I'm struggling to see the wood for the trees, which I suspect is down to my lack of knowledge around how things hang together. I figured I'd go for some easy stuff to start with, so had a look at HADOOP-10861. Most of the html I can find under /hadoop-hdfs-project/hadoop-hdfs/src/main/webapps seems to be valid. After further digging I found HDFS-274 which appears to be a patch for the pages when they were .jsp instead of html, so does this just need closing? So essentially this boils down to two mains questions: * How do I know if a newbie Jira is even still valid? * Does anybody have any suggestions for a suitable newbie ticket to pick up? Thanks Darrell
Jenkins build is back to normal : Hadoop-common-trunk-Java8 #174
See https://builds.apache.org/job/Hadoop-common-trunk-Java8/174/changes
Re: IMPORTANT: testing patches for branches
On Apr 22, 2015, at 11:34 PM, Zheng, Kai kai.zh...@intel.com wrote: Hi Allen, This sounds great. Naming a patch foo-HDFS-7285.00.patch should get tested on the HDFS-7285 branch. Does it happen locally in developer's machine when running test-patch.sh, or also mean something in Hadoop Jenkins building when a JIRA becoming patch available? Thanks. Both, now that a fix has been committed last night (there was a bug in the Jenkins handling). Given a patch name or URL, Jenkins and even running locally will try a few different methods to figure out which branch to use out. Note that a branch name of ‘gitX’ where X is a valid git reference also works to force a patch to start at a particular commit. For local use, you’ll want to use a ‘spare’ copy of the source tree via the —basedir option and use the —resetrepo flag. That will enable Jenkins-like behavior and gives it permission to make modifications and effectively nuke any changes in the source tree you point it at. (Basically the opposite of the —dirty-workspace flag). If you want to force a branch (for whatever reason, including where the branch can’t be figured out), you can use the —branch option. If you don’t use —resetrepo, test-patch.sh will warn that it thinks the wrong branch is being used but will push on anyway. In any case, the result of what it thinks the branch is/should be will be in the summary output at the bottom along with the git ref that it specifically used for the test.
RE: IMPORTANT: testing patches for branches
Overall approach and summary is very good... well done Apart from steve pointed which I had also noticed, following one also i had seen where I did not seen any clue.. The patch artifact directory on has been removed! This is a fatal error for test-patch.sh. Aborting. Jenkins (node H8) information at https://builds.apache.org/job/PreCommit-YARN-Build/7477/ may provide some hints. ( did I miss here something ) Atlast one suggestion is : can we remove whitespace check..? Thanks Regards Brahma Reddy Battula From: Sidharta Seethana [sidharta.apa...@gmail.com] Sent: Friday, April 24, 2015 12:27 AM To: common-dev@hadoop.apache.org Subject: Re: IMPORTANT: testing patches for branches About (3.) , a lot of the check style rules seem to be arcane/unnecessary. Please see : https://issues.apache.org/jira/browse/HADOOP-11869 On Thu, Apr 23, 2015 at 10:45 AM, Steve Loughran ste...@hortonworks.com wrote: 1. I really like the new patch process, especially the at-a-glance summary 2. I think being -1 on whitespace is overkill; Its just part of my git apply -p 0 -3 --verbose --whitespace=fix action. Accordingly, I won't reject patches on whitespace alone. 3. if checkstyle is complaining, how to track it down? As example, I don't see much from: https://builds.apache.org/job/PreCommit-HADOOP-Build/6167/artifact/patchprocess/checkstyle-result-diff.txt On 23 Apr 2015, at 12:21, Allen Wittenauer a...@altiscale.com wrote: On Apr 22, 2015, at 11:34 PM, Zheng, Kai kai.zh...@intel.com wrote: Hi Allen, This sounds great. Naming a patch foo-HDFS-7285.00.patch should get tested on the HDFS-7285 branch. Does it happen locally in developer's machine when running test-patch.sh, or also mean something in Hadoop Jenkins building when a JIRA becoming patch available? Thanks. Both, now that a fix has been committed last night (there was a bug in the Jenkins handling). Given a patch name or URL, Jenkins and even running locally will try a few different methods to figure out which branch to use out. Note that a branch name of ‘gitX’ where X is a valid git reference also works to force a patch to start at a particular commit. For local use, you’ll want to use a ‘spare’ copy of the source tree via the —basedir option and use the —resetrepo flag. That will enable Jenkins-like behavior and gives it permission to make modifications and effectively nuke any changes in the source tree you point it at. (Basically the opposite of the —dirty-workspace flag). If you want to force a branch (for whatever reason, including where the branch can’t be figured out), you can use the —branch option. If you don’t use —resetrepo, test-patch.sh will warn that it thinks the wrong branch is being used but will push on anyway. In any case, the result of what it thinks the branch is/should be will be in the summary output at the bottom along with the git ref that it specifically used for the test.
