+1 On Fri, Jan 10, 2025 at 11:06 PM Paul Irwin <[email protected]> wrote:
> Naturally I vote +1 as well. With 4 binding +1 votes, and no -1 votes, this > vote passes. > > I will work with Shad on setting up the new repo, move the code over, and > set up NuGet distribution and usage in our project. > > We're still open to hearing any concerns or answering any questions, of > course. Thanks! > > Paul Irwin > Lucene.NET PMC Member > Apache Software Foundation Member > > > On Tue, Jan 7, 2025 at 10:13 PM Shad Storhaug <[email protected]> > wrote: > > > +1 > > > > For those interested, the project has existed for a couple of years but > > hasn't been given a lot of attention and has not had versioned NuGet > > distribution: > > > > https://github.com/NightOwl888/lucenenet-codeanalysis-dev > > > > It needs to be cleaned up a bit and some documentation added, and some of > > the existing (noisy) rules should be disabled by default, but I think we > > can keep everything that exists and add to it and move it into an Apache > > repository. The best way to understand what they do is to look at the > > Resources.resx file. > > > > Analyzers are pretty easy to make and very useful for finding very > > specific use cases that would be extremely difficult to do using find > (even > > with regex), such as finding all of the ToString() calls that apply to a > > narrow set of types. These types of searches may be rare to do, and for > > those one off cases we can just make disabled by default, but keep them > > handy in case we need them again. The primary benefit will be to enforce > > coding rules that are very specific to this project and make it easier > for > > contributors and code reviewers to understand when a rule is in place > that > > has been violated. > > > > Giving this a proper distribution channel (that is versioned so it will > > sidestep any IDE caching issues) will help to expedite the development of > > these analyzers. > > > > Regards, > > Shad Storhaug (NightOwl888) > > Project Chairperson - Apache Lucene.NET > > > > -----Original Message----- > > From: Paul Irwin <[email protected]> > > Sent: Wednesday, January 8, 2025 4:07 AM > > To: [email protected] > > 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 > > >
