Bugs

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bugs

Grant Ingersoll
So, being the newbie committer, I have been looking through the bug list
trying to figure out where I can contribute some help.  It seems to me
like there are a lot of patches/bugs that are languishing (through no
one's fault, we are all busy and this is a volunteer project).  I know
you can vote on bugs and also give bugs a priority, but I am not sure
how useful these are at this point since the highest vote getter is
Issue 443 with a sum total of 5 votes (hardly a mandate) and a lot of
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
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... :-)

If this is useful, is there anyone that is willing to help?  Perhaps we
can divy them up.  I don't think you have to be a committer to
manipulate JIRA, just a "Lucene Developer" which we could probably grant
to someone if appropriate.

-Grant

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bugs

Chris Hostetter-3

: 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.

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:
  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

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
:)



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bugs

Grant Ingersoll
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bugs

Paul Elschot
On Thursday 15 June 2006 13:56, Grant Ingersoll wrote:
> Hey Chris,
...
> >  
> If you would like a second pair of eyes on anything, just let me know.

Some sandboxes were mentioned, where's the playground?

Regards,
Paul Elschot

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bugs

Chris Hostetter-3
In reply to this post by Grant Ingersoll
: > 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...

well, yeah ... but i suspect peoples natural dendency when searching for
bugs is to assume that if they are still having the problem it must not be
a resolved issue ... i freely admit that if i'm searching for a bug, and
don't find what i'm looking for with a lot of specific keywords, that i'll
eventually switch to only looking at open issues at as a relax my keyword
constraints and start gettting more and more things that only peripherally
relate  to the class/feature i'm searching on.

: > 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

: 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

Democracy in action: if people don't vote on issues, the politicians
don't know what issues the people care about; and if politicians don't pay
attenttion to the few people who do vote, there's less incentive for
people to vote :)

given the size of the lucene user base, and how few issues have votes, i
would argue that an issue with *1* vote should be considereed a popular
issue -- but by all means start with the 5 vote issue if you're
comfortable with it.

: 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.

+1


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bugs

Otis Gospodnetic-2
In reply to this post by Grant Ingersoll
Grant - there are a ton of good patches from Paul in JIRA.  There was also that one from a person at IBM, I think, the one that improved performance of interleaved add/delete operations.  I think that one would be good to apply before it gets stale.

Other than that - yeah, go by votes, I'd say, although I suspect most people don't vote.  I try to vote when I remember and like the fix.

Otis

----- Original Message ----
From: Grant Ingersoll <[hidden email]>
To: Lucene Developer's List <[hidden email]>
Sent: Wednesday, June 14, 2006 7:52:01 PM
Subject: Bugs

So, being the newbie committer, I have been looking through the bug list
trying to figure out where I can contribute some help.  It seems to me
like there are a lot of patches/bugs that are languishing (through no
one's fault, we are all busy and this is a volunteer project).  I know
you can vote on bugs and also give bugs a priority, but I am not sure
how useful these are at this point since the highest vote getter is
Issue 443 with a sum total of 5 votes (hardly a mandate) and a lot of
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
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... :-)

If this is useful, is there anyone that is willing to help?  Perhaps we
can divy them up.  I don't think you have to be a committer to
manipulate JIRA, just a "Lucene Developer" which we could probably grant
to someone if appropriate.

-Grant

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]