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 infrastruct...@apache.org or file a JIRA ticket