Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/209
> 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...
It's both a blessing and a curse. For example, we would never be able to
pull this off without the resources of the CI account (TeamCity) that we have
setup. It takes at least an hour to run the tests on each platform, so we need
something we can run them in parallel on for at least that long. I tried this
with MyGet and it turns out there is a limit to 15 minutes per build. So,
having a full CI server with huge amounts of storage and RAM is a good thing. I
also got some help from the team setting it up.
Also, Apache requires that all code must be testable before being released
(implying there must be tests), and ensure that the licensing is all legal, all
code files have license headers, etc.
But not being able to setup your own repo (because they are hosted by
Apache) and having to deal with JIRA instead of just using GitHub's issue
tracker causes some friction.
Could there be Lucene.Net without Apache? I don't know. There must be some
reason why no developer before me went off on their own and decided to pull it
out from under Apache (and I don't think there is anything in the licensing
preventing it).
But we do what we can. Recently, there have been more contributions than
since I started working on this a year ago. I am not sure if that is because we
are now so close to the finish line, or my efforts of updating documentation,
getting a release on NuGet, etc are starting to pay off.
But I think that to help combat this we really need to update the
documentation, website, simplify deployment, etc. and generally make Lucene.Net
a good place to work. Key among these things is to lower the bar for how
difficult it is to add search to an application, and that is what I am hoping
to achieve with these integration packages (which in turn should increase both
downloads and contributions). But of course, if you would rather use the
low-level APIs directly they are not going anywhere.
> 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 >.<)
Yes, it is probably similar. Although it will probably end up being an
`IIndexAccessor` or something along those lines.
It sounds like you are not too familiar with dependency injection (which is
why I am following this approach), and although you can certainly get by
without it, it is definitely something every developer should know going
forward. I was reluctant to read up on DI at first and wasn't sure that doing
so would be worth the time, but ever since I read [Dependency Injection in
.NET](https://www.manning.com/books/dependency-injection-in-dot-net), it has
forever changed the way I write code. And out of dozens of books that I have
read there are very few I can say have accomplished that. But as they say, you
can lead a horse to water, but you can't make them drink - do as you will :).
> Anyways, this is derailing things a bit, it was just some input for you
going forward. So we should probably get back to focusing on the actual
Lucene.Net.Replicator, and comments in there >.<...
> Ill see if I can find a suitable place for that little demo app.
Thanks again. Replicate away! And if you can, find a way to replicate
contributors :).
---
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
with INFRA.
---
