You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nutch.apache.org by Lewis John Mcgibbney <le...@gmail.com> on 2012/11/29 14:54:45 UTC
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: Strategy for Assigning Issues by Version
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+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 <li...@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
Posted by Lewis John Mcgibbney <le...@gmail.com>.
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.digitalpebble@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
Posted by Julien Nioche <li...@gmail.com>.
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
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
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.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++