NightOwl888 commented on issue #793: URL: https://github.com/apache/lucenenet/issues/793#issuecomment-2439666039
> No one denies the developers' efforts. But the world is essentially competitive. If you are behind, you will lose your share, and your users will be reduced, and the development progress will be slow, forming a vicious circle. You are right. The numbers don't lie. It is a vicious circle. Time for a quick math lesson. Take a seat. I worked 7 days this week for 12 hours each day. How many days are in a week? 7 days. Quick math - how many more days can I work in a week? That is right, 0. Lucene.NET has over 450,000 lines of code. It depends on functionality that doesn't exist in the BCL. All together, we are maintaining over 600,000 lines of code including those dependencies. This is not simple code. It goes deep into dozens of different technologies. Most of these things I have never had to deal with in over 20 years of programming. And the way things are done in Java simply don't translate well to .NET in a multitude of ways. All that we have left are the gaps at the edges of the application, but there are some very big gaps. Now, how many people regularly contribute to Lucene.NET? 4 or 5? Yeah, that is about right. But look closer. How many are contributing to the *code*? Currently, only 2. Most of the time it is 1. Quick math. What is 600,000 divided by 2? How about divided by 1? Do you see the problem now? Ever write a randomized test framework that is capable of repeating the random scenario so the test fails reliably with the same seed? Ever package an app with satellite assemblies representing over 750 languages? Ever implement the part of Unicode that .NET doesn't support? Ever copy a formatter out of the BCL just so you can add functionality to it because Microsoft didn't make it extensible and we need that feature? How about writing code that can put a ref struct or an interface into the same variable without any boxing? Probably not. How long do you think it would take you? Now how about if you multiply it by 30 things you have never worked with before? I have over 6,000 hours of my time invested in this project and its dependencies, and that is being conservative. I have worked with more diverse technologies in the past 3 years than most people will ever touch in their entire career. Paul Irwin returned recently to ensure the hard work that he invested in this project over a decade ago will be released. He is doing his part, and is invaluable to the project. What was your contribution? One complaint? Make that two. Do you seriously think a complaint is going to make us go faster? Do you think we have time to consider that you are being clobbered by your competition because you decided to sit back and wait instead of jump in and help? We don't spend one second thinking about this. We are *completely overwhelmed* by the amount of work there is left to do. It is *beyond absurd* to expect us to find extra time to include anything that isn't already in Lucene or isn't something directly related to closing a gap. The project isn't being delayed. It is going as fast as we can go. But there is only so much a couple of people working on the code can achieve when it comes to the release. The people working on the website and helping keep up with the revolving door of target frameworks are also important. They are at least doing their part to lighten the load. As for "losing shares", here are some real numbers: - In 2016, we got about 600 downloads per day. - In 2024, we are getting about 7000 downloads per day. So, we are not losing shares. It is you who is losing. You depend on a stable release. But you don't care enough to help get it done. The decision to wait instead of help was entirely yours, and you are losing because you made the wrong decision. Lucene.NET is not stable. The API has planned breaking changes that are not even started yet. - The analyzer calls dispose and then expects the class to still be functional, so we are planning to change it to use a `Close()` method instead so `Dispose(true)` can be used to do a final cleanup. - There is code that was generated in Java that has been hand-ported in .NET. That is the quickest way, but isn't going to be maintainable in the long term. Changing public APIs to be generated in a way that is more sensible in .NET will almost certainly introduce breaking changes in both the API and behavior. There is more than this, but my point is that we have breaking changes planned and we only get one shot at the version number 4.8.0. The next version number we will use is 4.8.0.1 because version 4.8.1 implies that we have ported Lucene 4.8.1. This doesn't leave much room for breaking APIs since nobody expects 4.8.0.1 to be a breaking change from 4.8.0. I have some ideas on how to work around this for obscure APIs, but for the primary ones, breaking binary changes are not acceptable for a stable release. We *just* fixed the last known concurrency bug in the Lucene.Net core module, which will be fixed in 4.8.0-beta00017. We also put in some low level native API calls to implement the fsync functionality that we were missing. But we recently found and ported a missing test that revealed that our [ACID support is broken](https://github.com/apache/lucenenet/issues/894). About 1 power outage out of 200 during a commit will result in a corrupted index. Does that sound stable to you? This is database 101 kind of stuff, and we are not there yet. I am out of my depth with this problem and we could use someone who is familiar with the implementation of database fault tolerance and durability (or someone willing to learn) to step in and help. The vicious circle is that for companies who require a stable release, every year that passes by they are losing out by not helping or funding us so we can get more help. We need players on the field to pass the ball to or we cannot move any faster. The Lucene.NET project is not letting the Lucene.NET community down. But the Lucene.NET community is letting the Lucene.NET project down by not helping or providing funding to get it done. We have an entire plan in place to catch up with Lucene's release schedule. But we will never hit a moving target with this many lines of code and so few people. It would be absurd to even try it. So, now the ball is in your court. And by you, I am referring to the entire Lucene.NET community reading this. If you want a stable Lucene.NET release, you have 3 options: 1. Help 2. Fund - contact me through the email on my GitHub profile if you would rather fund the project as a whole than one developer 3. Wait The action you take next will demonstrate just how serious you are about wanting a stable Lucene.NET release. **You have much more power to change the release date than I do.** There is a push to try to get the production release out before the end of the year. I don't think it can be done with only 2 people working on the 4.8.0 blockers even if we take as many shortcuts as we can. But with a few more people working on the blockers and helping to drive ICU4N to a stable (but incomplete) state, I think it is plausible. Now for one last bit of math. Looking at my watch, it has been 4 hours since I started typing this. So did your complaint-as-a-contribution to Lucene.NET shorten or lengthen the time it will take us to release? That's right, you have just delayed the release by half a day by prompting me to reply. It took me away from other tasks I was doing. I am sure the Lucene.NET community as a whole really appreciates your contribution. But don't worry, you can submit a PR for a blocker to put us back on track again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
