Since @Meatball is about to “retire”, I’d like to put myself forward as a replacement maintainer for the Swift track. The track is in good shape, but there’s still a lot that can be improved and leaving it without a maintainer feels sad for me.
I can put together a more detailed plan, but here’s a quick recap of what I’d like to work on:
- Continue improving the
swift-runner. I’ve already spend some time improving exercise build time, but I’d also like to invest some time into swift code safety and cleanliness. Docker build time and size it also what I’d like to research.
2 Updating to Swift 6.2 — both the exercises and the tooling.
- Polish, finish and release the Swift Analyzer that @Meatball has been working on.
- Get rid of exercise-specific plugins in the test generator. This feels weird for a general tool.
- While I’m mostly drawn to contributing to the tooling, there’s also plenty to do in the track itself, like adding new practise exercises.
- I’m not yet fully sure what the full list of regular maintainer activities look like. As far as I know, there’s a need to periodically sync exercise info from the canonical-data repo and review the track feed on the forum.
Looking forward to contributing to the Swift track!
1 Like
The responsibilities are documented here: Maintainers | Exercism's Docs
Notably, there’s no requirement that a maintainer add practice exercises themselves. Sometimes, maintainers do add exercises (I regularly do), but that’s not expected.
1 Like
The initial version of the analyzer someday soon. It is actually finished but if I can recall there are something which has to be done but just forgot.
Get rid of exercise-specific plugins in the test generator. This feels weird for a general tool.
The idea behind having exercise-specific plugins is that they are quite difficult to do just in the template. And they are so specific that they don’t become applicable to other exercises. And its goal is not really to be a “general” tool. The swift generator is for example only made to work in Swift for example, it couldn’t (without adding more plugins) be able to create test files for other tracks.
1 Like
Yeah, that doesn’t strike me as unusual for tracks with full-blown test generators. OCaml for example has a lot of exercise-specific overrides. To get rid of overrides, you could do something like the Vim Script track’s generator. That gets about 80 or 90% of the way and then the human puts the finishing touches on the test suite. That’s generally not a problem since new tests don’t get added too often.
That’s completely fine. What I mean, the overall concept should be that it’s better to have a finite set of plugins that cover all possible test descriptions or at least try, rather than adding a new plugin for every new format. For example, the listOps plugin is specific to one exercise, I believe. A better approach would be to add a general plugin that allows replacing some occurrences with another.
1 Like