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. Otis --- 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 > 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 > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-dev-help@jakarta.apache.org