This is not directly about code or any concrete technical-only reason to create an RFC (?).
I think that the important_packages idea is good, but every time the evolution of the compiler may break or flaky some package test, like when a symbol is deprecated or removed, the core devs should NOT spend time and efforts fixing some random user projects to make the Nim CI pass, also sometimes the pull requests have to wait on the user responses and merges (that user may not be even actively coding anymore), because when all this in-between process happens the Nim pull request that was ready to merge now may be out of sync with devel by several commits, I understand the "good intention" and all, but I think is critical for the core devs to focus on fixing the Nim compiler, to use all available possible manpower and developer-time to fix Nim.
Being listed in the important_packages should be like a way to "highlight and honor" a Nim project.
If that package is not actively fast moving to keep up with the evolution of Nim compiler anymore, then it should be removed from the important_packages (or commented out at least), projects should move forward by its own traction, and not implicitly stealing developer-time from the Nim compiler. Projects can always setup their own stricter CI anyway.
TLDR if a project in important_packages breaks a test in devel, then it should be removed from important_packages, not "try to PR it".
As far as I know important_packages was created _specifically so that popular or big enough Nim libraries/packages are tested, so that library/compiler developers won't have to spend a lot of time chasing down bugs after releasing a stable version.
As with all other software, not a lot of people test development versions, so IMO having important_packages is, well, important.
If a package is "important" it should be compatible both with the next Nim version and the current one. If it's not getting updated then a fork of it with fixes should be tested. A package being important doesn't mean it has to be the best package either, as long as it's commonly used I think it's important.
Not to mention not all PRs to Nim are good ideas. There's not always a good reason to deprecate/remove stuff, and existing packages can sometimes be evidence of this.
I think is critical for the core devs to focus on fixing the Nim compiler
Fixing the Nim compiler would imply making packages continue to work. Compiler devs should never have to make PRs to important packages.
I would really like to know specifically what you're talking about as someone who has made both compiler and standard library PRs, including deprecations/removals, and had to PR to some packages. I've never considered it a hindrance or a bad thing.
like when a symbol is deprecated or removed
Just don't? ie actively spending time on breaking packages seems like a counterproductive thing to be doing, and we've had this discussion in many PR:s - it does a disservice to the Nim community because fewer working packages are available for users, downstream developers have to spend time on sorting out why their things broke and it often has ripple effects because one package breaking means all packages using it break to, transitively. Your "progress" is everyone else's loss.
It's easy to make a removal PR when you don't have to pay the follow-up price of fixing the fallout - important_packages in that sense serves to balance the cost and assign it where it belongs: with the author of the breaking PR - it's good mechanism design.
The compiler and language is not hurt by these symbols existing: you don't want to use them? that's fine - they get skipped over - you can import a different module or project in your projects and life will go on. If you want new functionality different from the deprecated version, that's ok - we deprecate things in the standard library to announce that a better version with fewer caveat exists and to guide users to use them: that doesn't mean the previous versions didn't work - clearly they successfully solved a problem since they're still being used.
It is a rare and exceptional case that removal is needed - you will know when that happens, because you will have no trouble motivating to the community that they should get involved and upgrade their packages - if this is difficult, the problem lies with the quality of your removal PR, not the code that uses the deprecated library function.
Something to mention regarding hindrances to development: This is a bit unrelated and may be derailing, and I truly mean no disrespect to anyone, but I have to say this at least once.
The entire first paragraph in your post is one sentence. There are no periods. English like this is extremely hard to parse and I have to guess what it means most of the time and selectively pick words and parts of sentences to make sure I guessed correctly, and sometimes that still isn't enough.
This is a problem that comes up a lot when discussing issues and proposals on GitHub, and it's not specific to one person. It actively makes discussing development difficult, and it's even worse when it reflects on users in documentation/changelogs. I have a wild guess this is why a lot of people don't interact with the community outside Discord.
My native language isn't English either, not even close to it, and I don't blame anyone for not being proficient in English. But bad English is worse than no English in my opinion. Maybe we should encourage people to speak their own languages and have more multilingual documentation or things like that, but the truth is that Nim's development is done in English and not using it effectively can be a problem.
Nim is special in that it has a diverse userbase and isn't developed by a single real-world entity or people who know each other. We need to put extra effort into accounting for this diversity so that we can maintain it.
Sorry if I'm exaggerating. I'll keep this to myself next time.
That said, I also agree that it's important for libraries themselves to add devel Nim to their CI (which is quite easy), because the main Nim CI doesn't run on infinite servers, and with each library the CI time is slowing down.
we do, but the problem here is that it takes up a lot of time seeing a regression on devel and hunting down the "improvement" that broke things, and then spending time on explaining to the author why it's important to not break things unless there's an important reason - important_packages filter out the most obvious cases and are a great boon both to Nim, its community and those of us that actually write and publish lots of Nim code.
I'll give a recent exemple, this PR broke libp2p (and other repos), we noticed it fast since we have daily CI running against unstable
It was supposed to improve enum resolution, but evidently made it worst since it broke existing code. Now that it's merged, I doubt it's going to get changed, unless someone pushes a lot for it (I already tried on the PR without much effect)
If libp2p (or other affected package) was part of the important_packages, it would have prevented this PR from being merged as-is, and at least start a discussion on "Does this PR make sense"
Same thing happened with nimPreviewDotLikeOps, which actually made the "dot like ops" worst than what they were before instead of improving them, and took months to be reverted. Meanwhile questionable and any repo using it wasn't usable on Nim devel.
The fact is, once something is in Nim's devel it's a bit painful to revert / fix. Maybe the original author isn't around anymore, or he just doesn't have time / motivation to continue working on it. So we better make sure something is good before merging it.
Giving the PR author ability to see what his PR is breaking, and letting him check if this breakage make sense (ie, the package might be relying on sketchy behavior) is very positive IMO
With overloadable enums specifically, packages breaking the way they did was expected. I made an issue detailing the exact difference with no overloadable enums that breaks packages, then I made an RFC to deal with it, but it was decided that the behavior that comes with overloadable enums is better.
This behavior being that enum fields with the same name should be considered ambiguous regardless of which scope they are in (i.e. locally defined enums are not prioritized over enums in imports or higher scopes). The way to adapt packages to this is literally just to qualify enum fields. The error message for values with ambiguous types are pretty bad, but that doesn't change the fix, and that problem exists no matter what you do about overloadable enums.