lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Isakson" <Eric.Isak...@sas.com>
Subject RE: 1.3 release
Date Thu, 10 Apr 2003 16:11:34 GMT
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 http://marc.theaimsgroup.com/?l=lucene-dev&m=104810964328376&w=2
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 http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Lucene&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&order=bu

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         http://www.sas.com



-----Original Message-----
From: Doug Cutting [mailto:cutting@lucene.com] 
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: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message