Re: [VOTE] Apache Nutch 1.6 Release Candidate
Hi, On Wed, Nov 28, 2012 at 10:11 AM, Julien Nioche lists.digitalpeb...@gmail.com wrote: - CHANGES.txt contains dates in both MM/DD/ and DD/MM/ formats. Shall we write the month in text form e.g. 7th July 2012 from now on? Done - Don't we need to have signatures as part of the RC? Done, thanks for the attention to detail Julien. Best Lewis
Strategy for Assigning Issues by Version
Hi All, Right now I found myself facing a bit of a dilemma w.r.t bumping on the issues for the next Nutch release. Currently due to legacy workflows, we have some 120 issues assigned for 1.6... however ALL issues have been addressed for 1.6 meaning that the 120 issues are for 1.6 however not necessarily for 1.7. A suggestion from myself, can I mark these issues as no fix version? This means that we can carve/manufacture the next development drive to what developers want to fix and to what features requests we receive from the community rather than sitting with a constant pile of issues which are always for the next development drive. Additionally, may I suggest (and please shoot me down here if I sound cheeky) that we make it a priority in the next development drive, to harness the issues which are marked as patch submitted? It seems to be a waste for such issues to be stagnating. I am conscious that this comment may sound wide of me, this is not the intention, I do think however that it would be nice to work our way towards Nucth releases in a more strategic manner than we have been doing. Hopefully this proposal is a step in the right direction. Thanks for any feedback. The issue at the top I suppose is the most important one in the short term. best Lewis -- Lewis
Re: [VOTE] Apache Nutch 1.6 Release Candidate
Thanks guys. I should review this today. Cheers, Chris On Nov 29, 2012, at 5:31 AM, Lewis John Mcgibbney wrote: Hi, On Wed, Nov 28, 2012 at 10:11 AM, Julien Nioche lists.digitalpeb...@gmail.com wrote: - CHANGES.txt contains dates in both MM/DD/ and DD/MM/ formats. Shall we write the month in text form e.g. 7th July 2012 from now on? Done - Don't we need to have signatures as part of the RC? Done, thanks for the attention to detail Julien. Best Lewis
Re: Strategy for Assigning Issues by Version
Hey Lewis, On Nov 29, 2012, at 5:54 AM, Lewis John Mcgibbney wrote: Hi All, Right now I found myself facing a bit of a dilemma w.r.t bumping on the issues for the next Nutch release. Currently due to legacy workflows, we have some 120 issues assigned for 1.6... however ALL issues have been addressed for 1.6 meaning that the 120 issues are for 1.6 however not necessarily for 1.7. I would just set them for 1.7. I just use N+1 as the next release whether or not we actually plan to solve them for 1.7. Then when 1.7 comes along you can bump those 1.7s that we didn't get to, to 1.8, etc. A suggestion from myself, can I mark these issues as no fix version? This means that we can carve/manufacture the next development drive to what developers want to fix and to what features requests we receive from the community rather than sitting with a constant pile of issues which are always for the next development drive. Marking them as no fix version destroys pretty important reporting that I like to use which is pulling up a list of all the upcoming issues of relevance set for the next release. Without setting a Fix version you have to use the other JIRA search tools to search by things other than next version. Additionally, may I suggest (and please shoot me down here if I sound cheeky) that we make it a priority in the next development drive, to harness the issues which are marked as patch submitted? It seems to be a waste for such issues to be stagnating. I am conscious that this comment may sound wide of me, this is not the intention, I do think however that it would be nice to work our way towards Nucth releases in a more strategic manner than we have been doing. Hopefully this proposal is a step in the right direction. +50. That was one of my keys to success when I had more time. I would look for issues sitting with patches and just commit them. If I can wrangle some Nutch time over Christmas, I'll do a bunch of this as well. :) Thanks for any feedback. The issue at the top I suppose is the most important one in the short term. Cheers my friend. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: Strategy for Assigning Issues by Version
Good idea! I suspect that most of them will be dating from a looong time ago and it won't be such a straightforward task to apply them, however this would be a good way of sorting them Additionally, may I suggest (and please shoot me down here if I sound cheeky) that we make it a priority in the next development drive, to harness the issues which are marked as patch submitted? It seems to be a waste for such issues to be stagnating. I am conscious that this comment may sound wide of me, this is not the intention, I do think however that it would be nice to work our way towards Nucth releases in a more strategic manner than we have been doing. Hopefully this proposal is a step in the right direction. -- * *Open Source Solutions for Text Engineering http://digitalpebble.blogspot.com/ http://www.digitalpebble.com http://twitter.com/digitalpebble
Re: Strategy for Assigning Issues by Version
So in summary, We retain the legacy behavior and bump them ALL to 1.7 In the 1.7 development drive (if and when we can) we make an effort to act on patched issues in an attempt to pick the low hanging fruit so to speak... if such a thing exists. best Lewis On Thu, Nov 29, 2012 at 3:56 PM, Julien Nioche lists.digitalpeb...@gmail.com wrote: Good idea! I suspect that most of them will be dating from a looong time ago and it won't be such a straightforward task to apply them, however this would be a good way of sorting them Additionally, may I suggest (and please shoot me down here if I sound cheeky) that we make it a priority in the next development drive, to harness the issues which are marked as patch submitted? It seems to be a waste for such issues to be stagnating. I am conscious that this comment may sound wide of me, this is not the intention, I do think however that it would be nice to work our way towards Nucth releases in a more strategic manner than we have been doing. Hopefully this proposal is a step in the right direction. -- * *Open Source Solutions for Text Engineering http://digitalpebble.blogspot.com/ http://www.digitalpebble.com http://twitter.com/digitalpebble -- *Lewis*
Re: Strategy for Assigning Issues by Version
+50 :) On Nov 29, 2012, at 8:32 AM, Lewis John Mcgibbney wrote: So in summary, We retain the legacy behavior and bump them ALL to 1.7 In the 1.7 development drive (if and when we can) we make an effort to act on patched issues in an attempt to pick the low hanging fruit so to speak... if such a thing exists. best Lewis On Thu, Nov 29, 2012 at 3:56 PM, Julien Nioche lists.digitalpeb...@gmail.com wrote: Good idea! I suspect that most of them will be dating from a looong time ago and it won't be such a straightforward task to apply them, however this would be a good way of sorting them Additionally, may I suggest (and please shoot me down here if I sound cheeky) that we make it a priority in the next development drive, to harness the issues which are marked as patch submitted? It seems to be a waste for such issues to be stagnating. I am conscious that this comment may sound wide of me, this is not the intention, I do think however that it would be nice to work our way towards Nucth releases in a more strategic manner than we have been doing. Hopefully this proposal is a step in the right direction. -- Open Source Solutions for Text Engineering http://digitalpebble.blogspot.com/ http://www.digitalpebble.com http://twitter.com/digitalpebble -- Lewis
[jira] [Commented] (NUTCH-1499) Usage of multiple ipv4 addresses and network cards on fetcher machines
[ https://issues.apache.org/jira/browse/NUTCH-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13506650#comment-13506650 ] Walter Tietze commented on NUTCH-1499: -- @Sebastian, please don't mind, I'm not answering until now. In our cluster we also use the bonding driver. I asked the networkers of our partners already why they don't wanted to use this kind of configuration and still wait for their response. If I get the good reasons or not, I will inform you at once! Usage of multiple ipv4 addresses and network cards on fetcher machines -- Key: NUTCH-1499 URL: https://issues.apache.org/jira/browse/NUTCH-1499 Project: Nutch Issue Type: New Feature Components: fetcher Affects Versions: 1.5.1 Reporter: Walter Tietze Priority: Minor Attachments: apache-nutch-1.5.1.NUTCH-1499.patch Adds for the fetcher threads the ability to use multiple configured ipv4 addresses. On some cluster machines there are several ipv4 addresses configured where each ip address is associated with its own network interface. This patch enables to configure the protocol-http and the protocol-httpclient to use these network interfaces in a round robin style. If the feature is enabled, a helper class reads at *startup* the network configuration. In each http network connection the next ip address is taken. This method is synchronized, but this should be no bottleneck for the overall performance of the fetcher threads. This feature is tested on our cluster for the protocol-http and the protocol-httpclient protocol. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Jenkins build is back to normal : Nutch-nutchgora #419
See https://builds.apache.org/job/Nutch-nutchgora/419/
