Poll: Handling lucene-dev Merge
April 19, 2010 9 Comments
Lucene and Solr projects merged recently, as we mentioned in Solr Digest and Lucene Digest for March 2010. Today, their -dev mailing lists finally finally merged. Since Sematext runs the search-lucene.com service that makes these lists (and more) searchable, we need to decided how to handle this relatively drastic change.
We’ve identified 2 options, and we need your input to help us decide what the right option is:
- We can add a new lucene-dev list and start indexing it. This would contain only the new lucene-dev content (for both Lucene and Solr development from today on). This downside is that if you wanted to include old lucene-dev messages or old solr-dev messages in your search, you would have to explicitly select those lists. We could rename them to lucene-dev-old and solr-dev-old for example, so the UI would show lucene-dev, lucene-dev-old, and solr-dev-old. You’d have total control over what you want searched, but it would require you to make your choices explicitly, which also means people would have to understand what those -old lists are about and why there is no solr-dev.
- We could merge the old solr-dev and old lucene-dev, and have a single lucene-dev that has both of those lists’ old messages (up to today), as well as all the new messages from the merged lucene-dev list from here on. In effect, it would look as it Lucene and Solr always had a single lucene-dev list, since all of the old lucene-dev and solr-dev content would be in this new lucene-dev. If we go this route, there would be no lucene-dev-old or solr-dev-old in the UI, just one lucene-dev choice. But there also wouldn’t be solr-dev choice in the UI, since it doesn’t exist any more, which may be confusing. Thus, when you choose to search Solr, you wouldn’t see solr-dev facet in the UI, but the lucene-dev list’s content would be searched, so you wouldn’t actually miss any matches.
If there is a 3rd or 4th option that we missed, please let us know via comments!