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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
