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 wrong...
    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.

Reply via email to