Russell - great perspective and thanks for sharing. Matt,
If we reduce contribution and support for our existing 1.x line and its users to just code commits the data suggests things are going well. git shortlog --numbered --summary --since "Jan 1 2023" --before "Jun 30 2024" upstream/main git shortlog --numbered --summary --since "Jan 1 2023" --before "Jun 30 2024" upstream/support/nifi-1.x Quick analysis shows the same 7 people are present in the top 10 of both. This is a strong indication there are already great efforts being taken consistently by folks to backport where feasible and reasonable. Three of the top 10 for main who are not in the top 10 for support did all the work for the brand new UI. Fundamentally the data suggests things are going as they should and in general backporting happens as it should. If you expand beyond just code contributions to look at code reviews, slack, mailing lists, etc.. I think you'll also find a similar cast of community characters helping people on the 1.x and 2.x line. No sign of abandoning. We're still landing JIRAs, PRs, and releases on 1.x except now we have different folks engaged in generating the release candidates - which is awesome and so very much appreciated. As for concerns about my statement of atrophy you referenced I would appreciate your input on what is disagreeable. The sunsetting of Java 8, Spring 5, Jetty 9, and so on are very important and are unique concerns of the 1.x line. Some of these critical dependencies are vulnerable and we cannot solve them on the 1.x line due to choices of those libraries and the tie for specific versions to Java 8. The atrophy I reference is baked in due to these facts. Now perhaps a concern that is fair to surface is regarding the level of dependency maintenance happening on the main line vs that on the 1.x line. I bring this up because I personally have been focusing on these on the 2.x line and not on the 1.x line. Ironically the NIFi-12998 JIRA you reference as making backports problematic is an important change which helps make that line more dependency maintainable (among several other important improvements on main). NIFI-12998 would not have been feasible, and it was brutal to be clear, had others not already done awesome work on the 2.x/main line thanks to the updated dependencies and benefits of bill of materials patterns and so on. I have found dependency maintenance work is far more time consuming and error prone on the 1.x line than on the 2.x line but your mileage may vary. I read your note as raising concerns that the 1.x line isn't getting the support and effort it deserves to take care of our community as a whole. The data does not support that perspective. Not giving credence to the great work happening in the 2.x/main line to help the users have a strong path forward also seems to miss an important perspective. One of the most effective ways to take care of our 1.x users is to diligently provide a path to a strong and stable 2.x line. I'm extremely impressed by the work happening in the community at large and appreciative of everyone's efforts. Thanks On Tue, Jul 2, 2024 at 2:18 PM Russell Bateman <[email protected]> wrote: > I'm not too much of an end user though I get by. I have probably written > 60 or 70 proprietary custom processors (to handle the ingestion of > medical documents in my company's search engine). I want to call out > superb test runners and mocks that make processor development possible, > even a pleasure. How not to be grateful that what runs in JUnit while > developing never fails to run later in production? > > Mostly though, I wanted to thank all that have crafted NiFi v1 over the > years. Fixes have been prompt. Support via the mail groups and Slack has > been first-rate and courteous. > > Apache NiFi is dynamite software. It's rare to find a complex, magical > and so useful piece of software that you can get up and running in half > an hour with something real to show for it. And I mean show for it > because the UI makes it easy to demonstrate to management and other > non-technical folk the wizardry while it's going down. > > Thanks to all. > > Russell Bateman > > > > On 7/2/24 14:05, Matt Burgess wrote: > > There have been some ongoing discussions [1,2] about what to bring back > for > > PRs to 1.x vs trying to push forward with 2.x. There are of course great > > points from everyone. On the 2.x front, namely that 2.x has many > > improvements not just to components but the framework and UI as well, and > > that we've seen less contributions to the maintenance on the 1.x line. On > > the 1.x front that community members need to support 1.x for their users > > for the time being. > > > > I'm opening this discussion thread so we can collect everyone's thoughts > so > > the PMC can make a sensible recommendation/decision moving forward. For > > myself, I think all bug PRs should be backported where prudent/possible, > > and even new features (although that can be a difficult backport due to > > moving the extensions in [3], but I recommend a separate PR against 1.x, > > hopefully a simple copy-paste if there are no Java 21-specific code > issues, > > but please run contrib-check against Java 8 first). > > > > I disagree with the "atrophy" sentiment from [2], a mature release line > > normally experiences less contributions because it is mostly stable in > its > > own right. Guiding users to 2.x IMO is the right call but many of us have > > to deal with the fact that it doesn't usually happen overnight, > especially > > without a GA release. > > > > I opened this discussion with my opinions but if I may humbly speak for > the > > PMC, we need your voice, and we look forward to all of your thoughts, > > opinions, and questions. > > > > Thank you, > > Matty B > > > > [1]https://issues.apache.org/jira/browse/NIFI-13196 > > [2]https://github.com/apache/nifi/pull/9018 > > [3]https://issues.apache.org/jira/browse/NIFI-12998 > > >
