gh issue transfercommand line function, and it gave me an informative error: "Old issue cannot be transferred from private repository to public repository". Once I changed scijava-issue-shuttle to public, I was able to move them to the script-editor repo. Next time I'll try that command directly across orgs, and see if it works.
But there is no timeline and it contains goals that I do not fully support because they lead to eternal stasis: e.g https://github.com/scijava/incubator/blob/main/README.md#backwards-compatibility is unrealistic in a changing world, I agree that one should minimize this but it is necessary to break things if the old stuff is in the way and makes everything bad
Yeah, the timeline is unfortunately vague as I am transitioning to other projects in our community (e.g. napari-imagej), and @ctrueden has been stretched thin. The driving project behind SciJava 3, SciJava Ops and ImageJ Ops2, is nearly ready, but it of course depends on a bunch of components in SciJava 3.
logpackage in SciJava Common. It breaks backwards compatibility, naturally. Once SciJava Log2 has been released, any desired breaking changes would warrant SciJava Log3.
I also don't see who is actually working on this to make it happen, from the fiji meetings I read that you guys are all about doing pyimagej and writing papers at this time. Our own Fiji independent projects are currently using pom-scijava but we have bumped the release version so we can use modern stuff on the side of 8-compatible libraries (which works fine).
I was/am the driving force behind this, but now I'm only spending about one day a week on it. Furthermore, the incubator projects are in serious need of code review.
When we got this error before, it's because the build was using a too-old version of the maven-gpg-plugin. But I specifically have a hack in the
gpg: signing failed: No such file or directory
ci-build.shto force it to at least 3.0.1, the minimum working version.