lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject RE: 1.3 release
Date Thu, 10 Apr 2003 16:30:37 GMT
This sounds very good to me.
I am following Commons HttpClient development, and the people there
make a really extensive use of Bugzilla for tracking tasks, bugs,
enhancements, for release planning, etc.  They do a much better job
using Bugzilla than Lucene developers do.

So yes, I would welcome the move of todo.xml items to Bugzilla, change
of the link, removal of todo.* from CVS, and update of the site.  I
think that would be a good idea.

Thanks for thinking and helping!

Oh, and regarding Snowball Analyzers, if I recall correctly the
majority was for building it as a separate Jar.  Yes, the code for that
is not in build.xml yet.


--- Eric Isakson <> wrote:
> Stating my opinions on this. Sorry ahead of time if anyone feels I'm
> rocking the boat with these comments.
> The todo.xml file in the xdocs dir should go away and its items
> should be added to bugzilla. I just reviewed that file and think a
> few things in there have been resolved but not noted. I don't think
> anything in the TODO file should stop 1.3 final.
> The three responses in this thread so far should also be added to
> bugzilla and classified as enhancement requests.
> I've been using 1.3RC1 for a while and it seems stable in my uses. 
> I'm not using the snowball analyzers but they aren't core anyway, so
> shouldn't hold up 1.3 going final. As to releasing them in something
> like a snowball-analyzers.jar, there was some talk about that, but I
> don't believe it was ever added to any build. Did anyone do the work
> to make those analyzers available? I do recall bringing up a license
> issue about that but not being a lawyer, I don't know what we are
> _really_ allowed to do. See
> I
> think we are allowed to redistribute that code, but we need to make
> sure we are compliant with their license.
> I do use Che Dong's CJKTokenizer for japanese support and it is
> working great. I don't use it for any of my non-CJK languages though
> and would be hesitant to adopt it into a 1.3RC2 (which I think is
> what we'd need to do) unless we want to wait a little bit longer for
> 1.3 to be final. A change on that scale should probably get some time
> in the field before it is adopted as a final release since it has the
> potential to affect so many users of lucene.
> I didn't follow the dicussion about the modification on
> SegmentTermEnum so I can't say anything definitive about it, but it
> sounds to me like something that is an enhancement and doesn't really
> need to hold up a 1.3 final release.
> If we get all these things in bugzilla, we can then set priority on
> the bugs in bugzilla and you should be able to answer the question
> "Are there any bugs in 1.3RC1 that are so serious that 1.3 final
> should be delayed?" by reviewing the bug list. Folks can add comments
> to the bugs and/or spawn discussions here based on the bugs. Adding
> comments directly in the bugs (which all get forwarded here anyway)
> keeps the "memory" about the bug in one place when someone goes to
> resolve it.
> If you guys agree that this is an approach we should take, I'd be
> willing to take the time in the next day or two to add the todo items
> and other responses to this thread to bugzilla and change the link in
> xdocs/stylesheets/project.xml to a link to
> This is a severity sorted list of all open, new or reopened bugs in
> Lucene for any version. If you want separation of core vs. non-core
> bugs, we should be able to classify bugs under a component and filter
> the bug list by component. Not sure about version, probably need a
> separate discussion about what should be done with bugs that are open
> in say 1.2 but fixed in 1.3, it is still useful to know that the bug
> exists in 1.2 and wasn't fixed there. I'm used to bug tracking that
> allows me to have multiple version/status pairs for a bug, how is
> this done in bugzilla? If I fix a 1.2 bug in the latest CVS, do I
> just mark it fixed?
> I'm not suggesting we shouldn't have the discussion on the dev list
> of whether we are ready to release, I'm just suggesting that using
> the bug tracking system should facilitate that discussion. It gives
> us a tool we can use to see what still needs doing in the release and
> a place to record the "memory" of the discussion without having to
> poor over the dev list, the bug database and the todo page.
> Eric
> --
> Eric D. Isakson        SAS Institute Inc.
> Application Developer  SAS Campus Drive
> XML Technologies       Cary, NC 27513
> (919) 531-3639
> -----Original Message-----
> From: Doug Cutting [] 
> Sent: Wednesday, April 09, 2003 1:04 PM
> To: Lucene Developers List
> Subject: 1.3 release
> Are there reasons not to make a 1.3 final release?  Are there any
> bugs 
> in 1.3RC1 that are so serious that 1.3 final should be delayed?
> Doug
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message