-
-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow marking exercise as un-actionable #23
Comments
I think via PR -> store it in
|
Agreed! |
An alternative thought: don't hardcode the exercises, but accept a special version string, such as "non-canonical" or "not actionable". |
UNVERSIONED would be a standard |
I don't mind either option (hard-coded or special version). Which version do people prefer? Please give this comment a thumbs-up for the hard-coded version, and a heart icon for the special version. |
The UPSIDES of using
The UPSIDES of using a hardcoded list here are:
|
@SleeplessByte, I do prefer that track maintainers can manage their own exercise version opt-out without having to submit a PR here. You do make some good points in favour of the list approach. On the bash track we decided to use the .meta/version file to hold the canonical version, and we added a special comment into the test scripts that allow track versioning. We added some code into the CI check script to verify the two versions remain in sync. |
My guess is that you would really only need to PR here once or twice, and it wouldn't be a regular thing. |
To me, this is the argument that makes we choose for the hardcoded list option. |
It is not clear to me if you mean both version bumps and description changes. Haskell track has 4 cases where we'd like to skip version bumps, but retain description changes. |
This was indeed what I was referring to. Sorry for the confusion! Is there any opposed to the hardcoded list option? |
@glennj I think is in favour of do it in the track repo, but will be okay with it being hardcoded. |
@ErikSchierboom, @SleeplessByte: I think hardcoding is fine. Sorry for taking time to respond. While having a grace period for track maintainers to respond (such that we get the most useful features across tracks for which there are maintainers who like to give input), I also think that the working group (which is currently @SleeplessByte, as far as I can tell from the commit history) define any deadlines to avoid response-time gridlocks. (Lately on the Haskell track we've been using e.g. the phrase "I'll give other maintainers 48/72 hours to respond before merging" to avoid this.) |
@glennj wrote:
So do I. The Haskell track's versioning policy says that packages with a version of 0.1.0.i should not be bumped. We have another undocumented preference of slightly diverging from canonical tests in a way that preserves the canonical version, exemplified here. But such versioning conventions are, as far as I know, not general across tracks. I'd like for them to be, but I don't know if we're in the right situation to expand on things derived from problem-specifications. So perhaps an easy workaround is to have hardcoded opt-outs in this repo until we have a more comfortable working environment for building more project-wide conventions? |
I agree with this. It's not expensive to change this later. |
I also agree with this. Let's settle for the hardcoded option for the moment. |
Sweet. I'm locking this as soon as I get to it and then I'll implement it. @ErikSchierboom @sshine please send me a list of slugs (slack) if you want me to kick-start yours. |
Lovely! |
Some exercises are specifically designed in a way that it cannot be based on the canonical data. Currently, those exercises show as a actionable; i.e. it looks like they need to be updated to the latest canonical data. It would be useful if we could allow marking these exercises as fixed or un-actionable (or whatever the appropriate term is), which means that they will never show up as actionable. Perhaps hard-coding them into the
tracks.json
file is the easiest solution, as it will allow track maintainers to easily submit PR's.The text was updated successfully, but these errors were encountered: