+1 - sounds like a good plan On Tue, 7 Jan 2025 at 14:07, Paul Irwin <paulir...@gmail.com> wrote:
> 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 >
