Hey Chris,
All good points. See some more of my thoughts below...
Chris Hostetter wrote:
> : them are listed as increased priority. There are also a number of bugs
> : that date back as far as 2002 which I highly doubt are all that useful
> : at this point unless someone wants to patch a specific branch.
> :
> : So, I guess I am wondering where I can be the most helpful? I would
> : like to propose we close out some of these older bugs as "Won't Fix"
> : (people will still be able to browse the closed bugs), perhaps any bug
> : before Jan. 1, 2004. Would this be useful? I don't want to just do
>
> -1 ... even old bug reports that were vague or never reproduced may still
> be of use to someone who encounters the same problem today and
> unfortunately, many people don't think to search "resolved" or "closed"
> bugs for similar problems.
>
>
It's kind of ironic that people working on a search engine wouldn't
think to search first! :-) Human nature, I guess...
> I'm all in favor of closing out issues that have been fixed independently,
> or are no longer applicable because the code/functionality
> involved has been deprecated or changed so much that the bug/patch is no
> longer meaningful ... but i don't like the idea of picking an arbitrary
> cut off point and saying "anything older then this is too old to worry
> about", each issue should be considered on it's own merrits, or left
> alone.
>
> : busy work, but I also want to have a better idea of where efforts should
> : be focused so we can continue to improve Lucene. Anyone have any other
> : ideas? Or maybe someone wants to convince me that there bug should be
> : worked on right away... :-)
>
> I would suggest you start by looking at the popular issues, and fix any
> bugs that you feel you understand well enough to fix, or commit any
> patches you feel you understand well enough to stand behind them ... if
> there aren't any, then either:
>
This is my point. It isn't obvious to me from JIRA what the popular
issues are (is it the one w/ a sum total of 5 votes????). I know what
is talked about a lot on the list, but volumes of emails to me usually
indicates people are still hashing out the idea and it isn't ready to be
committed.
> a) get to know the code well enough that you do feel comfortable
> fixing/commiting.
> b) move on to less popular issues in areas of the code you are
> comfortable with already.
>
> ...that's what i try to do when i have spare time
>
This has been my approach. For now, I am working on adding some
documentation on scoring (with Karl) and fleshing out the Flexible
Indexing. I feel like I know indexing pretty well, but not scoring, so
writing scoring documentation will be helpful.
> At this point, it's not an issue of what do i want to work on it .. it's
> when. There are open issues containing patches (with unit tests) that *i*
> submitted way back in the day, and even though i'm a committer now, i
> still haven't gotten arround to committing them because i feel a like i
> need to be cautious and carefull about reviewing any patch ... even my own
> :)
>
>
>
If you would like a second pair of eyes on anything, just let me know.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
|