lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jeme <>
Subject [GitHub] lucenenet issue #209: RFC: LUCENENET-565: Porting of Lucene.Net.Replicator
Date Wed, 09 Aug 2017 11:55:29 GMT
Github user jeme commented on the issue:
    > While I generally agree with your points, we are unfortunately obligated to work
within the confines of the Apache organization, which comes with its own set of conditions.
For one, there is a formal release process we need to abide by (including a vote process that
takes a minimum of 3 days per release), and I am not sure what is involved in setting up another
Apache repo (nor am I sure I really want to go down that rabbit hole).
    Holy crap... I am glad I am not under that umbrella, in an age of continuous delivery
and continuous deployment that sounds like poison... o.O...
    > That said, we could follow the Lucene project's example with their separate release
cycles of Lucene and SOLR: put everything into one repo and use separate tag names for each
product. At least they started out that way - now they are releasing both products at the
same time.
    > It probably makes sense, though. If we have a release vote on both product A and
product B and product B depends on product A, and product A doesn't pass the release vote,
then product B will be stalled anyway.
    Product B would always depend on a Released A. (Could be a Beta Release or Final Release,
but it would be something that was out there)... It would work the same way as if I choose
to create a package that used Lucene.NET...
    > Of course, there is an alternative - build these integration packages outside of
Apache's umbrella. But I am not sure what Apache's policy is in this regard (anyone?). Given
the current situation with Spatial4n and LuceneNetDemo being on Itamar's personal account
and no ability to push to them without being given special permission (by Itamar), and the
fact that most of the projects on NuGet that depend on Lucene.Net are either dead or dying,
it feels like this idea could go wrong as well. Sure, it is feasible for a huge team like
Microsoft to do this, but trying to pull this off with a small team probably isn't very realistic.
    I doubt very much that putting things in under ASF is what will keep it alive, actually
I would think the opposite as ASF seems like such a scary thing to get started with which
probably scares off allot of contributors... Besides, I think the thriving world of OpenSource
proves that even single person contributions can end up becoming projects with huge communities...
But ofc. you can't just put something into OpenSource and then think it will just take a life
of it's own... It requires effort... But again...
    I would say that a more likely cause for the many deaths of Lucene.Net dependent projects
was that Lucene.Net it self seemed to have died. I have even questioned my use of Lucene.Net
in favor for Solr/ELK due to the version gap...
    > But the fact remains that the recommendation is to use a singleton IndexWriter (or
Reader) per index, meaning if we didn't provide the tools do it with a simple straightforward
API, everyone would end up having to do the research how to do it and write the same boilerplate
code. And a lot of them would assume they could create an IndexReader instance on each request
(or register it with the wrong lifetime) and find out just how poorly that performs.
    Thats not a singleton though... without knowing for sure, I am fairly sure that it's not
just a recommendation in this context, firstly the writer needs to be configured with a specific
deletion policy and you create revisions based on the writer, so having multiple writers for
a single index sounds like something that would break... I am not sure though, I could be
    So what your talking about is having a registry of indexes (with writers and readers)...
That registry could be registered as a singleton... (Sounds much like my LuceneIndexContext
on a different project >.<)

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message