I would like to help maintain this repository, if that would be useful.
The context, briefly. On #61 the position was that there are "no plans for any new features in SCIP indexers in general" because the team is "focusing on support, prioritising customer support", along with "we'll be happy to review a PR adding this feature". That is a perfectly reasonable place for a company to be, and I am not asking anyone to change it.
But the practical effect is a backlog: main has had no commit since 27 May, and there are four open pull requests, the oldest from 1 June. Two of those are dependency bumps. Mine is #117, which adds Razor and Blazor indexing, and I am well aware it is behind three others that have waited longer.
So rather than adding to a queue nobody has time for, I am offering the other thing: to help work the queue.
I have spent a fair amount of time in this codebase. #117 is written in the project's own style, keeps every existing snapshot byte-identical across net8.0, net9.0 and net10.0, and adds a snapshot fixture rather than only asserting by hand. I am happy to review other people's pull requests, work through the dependency bumps, and generally keep the lights on, in whatever arrangement suits you: triage only, review rights, commit rights, or simply being a reliable contributor you can hand things to.
If a lighter-touch answer suits better, I have also asked over at scip-code/scip#468 whether the org that now holds scip-java, scip-go and scip-rust would consider adopting the indexers that stayed here. That is a governance question for the steering committee rather than something I am pushing for, and either route is fine by me.
Entirely understood if the answer is no, or if there are constraints here I cannot see from outside. Worth asking.
I would like to help maintain this repository, if that would be useful.
The context, briefly. On #61 the position was that there are "no plans for any new features in SCIP indexers in general" because the team is "focusing on support, prioritising customer support", along with "we'll be happy to review a PR adding this feature". That is a perfectly reasonable place for a company to be, and I am not asking anyone to change it.
But the practical effect is a backlog:
mainhas had no commit since 27 May, and there are four open pull requests, the oldest from 1 June. Two of those are dependency bumps. Mine is #117, which adds Razor and Blazor indexing, and I am well aware it is behind three others that have waited longer.So rather than adding to a queue nobody has time for, I am offering the other thing: to help work the queue.
I have spent a fair amount of time in this codebase. #117 is written in the project's own style, keeps every existing snapshot byte-identical across net8.0, net9.0 and net10.0, and adds a snapshot fixture rather than only asserting by hand. I am happy to review other people's pull requests, work through the dependency bumps, and generally keep the lights on, in whatever arrangement suits you: triage only, review rights, commit rights, or simply being a reliable contributor you can hand things to.
If a lighter-touch answer suits better, I have also asked over at scip-code/scip#468 whether the org that now holds
scip-java,scip-goandscip-rustwould consider adopting the indexers that stayed here. That is a governance question for the steering committee rather than something I am pushing for, and either route is fine by me.Entirely understood if the answer is no, or if there are constraints here I cannot see from outside. Worth asking.