Makes sense. +1
-----Original Message----- From: Paul Irwin <paulir...@gmail.com> Sent: Tuesday, January 7, 2025 4:07 PM To: dev@lucenenet.apache.org Subject: [VOTE] New Dev Analyzers Internal Process/Artifact Shad Storhaug (PMC Chair) and I would like to propose for approval a new internal process and contributor-focused artifact for Lucene.NET, the details of which are below. This email starts a 72-hour approval vote for PMC members. Lucene.NET already has some Roslyn code analyzers that we publish on NuGet.org for end users of our libraries, to help look out for i.e. improper usage. We have long wanted some Roslyn code analyzers for use by contributors to our libraries, to analyze the Lucene.NET code itself. So it is important to understand the distinction here: the existing end-user-focused analyzer libraries are not affected by this vote; this would be adding new contributor-focused analyzers that are not intended for public consumption nor published as an official project artifact like the end-user-focused analyzers are. These analyzers would look out for usage and style problems in our codebase that we would otherwise have to manually search for or review in PRs. It would also allow us to create "code fixes" that could let us automate fixing these issues in the IDE. Because analyzers can be run during build, this would also allow us to add automated checks for these issues that run during PR build validation time, helping contributors be alerted to issues and fix them themselves. Some examples of dev analyzers we've discussed: - Look for any calls to Lock methods after Dispose is called (#1073) - J2N collections performance (#985) - Proper usage of format/parse for numeric types (#924) It is important to recap: this analyzer will be an internal dev (meaning, for contributors) artifact, and not an official Lucene.NET project artifact. It should be as easy as possible for new contributors to pull in these analyzers and use them to contribute to Lucene.NET, including contributing to these analyzers themselves, but we should discourage public use of these analyzers for any other purpose. That said, we want to ensure we do this in a transparent way. To that end, we will set up a new Apache GitHub repo called "lucenenet-codeanalysis-dev," and these will be published to NuGet.org as Lucene.Net.CodeAnalysis.Dev. (Note that we were recently granted a reserved prefix by NuGet.org, so any Lucene.Net.* packages going forward can only be published by our NuGet organization. Any existing external packages with that prefix can continue to publish new versions and are unaffected.) Now, there is a technical constraint to be aware of, to explain why this will be its own repo. If you try to have your internal analyzers be a project in the same solution, IDEs including Visual Studio and Rider do not eagerly invalidate their caches and re-run the analysis when they change. It often requires not only cleaning the solution, but also restarting the IDE. This can hinder the actual development inner-loop of creating the analyzers themselves, but also can be a real problem when switching branches, as we do often in this PR-centric process. Our best solution to this is to have the internal analyzers live in their own repo, and be versioned independently of the Lucene.NET project. This will allow us to publish prerelease versions while we develop the analyzers, and when switching branches where the analyzer version differs, the IDE will automatically pull in the new version. The Apache Release Policy (https://www.apache.org/legal/release-policy.html) normally requires a certain process be followed, including a 72-hour release vote, for any project artifacts published "beyond the group that owns it." Per the policy: > Generically, a release is anything that is published beyond the group > that owns it. For an Apache project, that means any publication > outside the development community, defined as individuals actively > participating in development or following the dev list. Note the second sentence in particular. We believe that, per the policy, these analyzers that are intended to be used solely by individuals participating in development do not constitute an official project release, even if published in binary form to NuGet.org. It is the PMC's responsibility to determine our course of action here, and we are proposing that we do not consider this a "publication outside the development community." This means, in effect, that we are proposing that we will not require a 72-hour release vote for any internal analyzer package builds published to NuGet. Such a release vote would greatly harm the ability to iterate and improve these analyzers, given the technical constraints mentioned above. But keeping this in an Apache repo will ensure we allow this code to be available to the community as part of our project, even if just as inspiration for others in how they can add analyzers to their own projects. If approved, for transparency, we will make sure that these considerations are noted in the README of both repos, the README of the package when published to NuGet, and in our release documentation (https://lucenenet.apache.org/contributing/make-release.html). So, to recap for the purposes of the vote: - Our new dev analyzers will be published to their own new Apache GitHub repo, and note in the README that this is intended for contributor use only, and is not an official project release - We will publish these analyzers to NuGet.org, and likewise note in the README the same concerns - We will not require a 72-hour vote to release these dev analyzers, as they are not going to be intended for use outside the development community Only votes from the PMC are binding, but everyone is welcome to vote. Please reply with your +1 or -1 vote, with or without any comments. The vote passes if at least three binding +1 votes are cast. Thank you, Paul Irwin Lucene.NET PMC Member Apache Software Foundation Member
