ASF GitHub Bot commented on LUCENENET-565:

Github user NightOwl888 commented on the issue:

    > 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 :).

> Port Lucene.Net.Replicator
> --------------------------
>                 Key: LUCENENET-565
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-565
>             Project: Lucene.Net
>          Issue Type: Task
>          Components: Lucene.Net.Replicator
>    Affects Versions: Lucene.Net 4.8.0
>            Reporter: Shad Storhaug
>            Priority: Minor
>              Labels: features

This message was sent by Atlassian JIRA

Reply via email to