Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
This is not a MockK issue, but more a question/feedback to @oleksiyp (MockK's developer). I hope more people in the community feel this way. If so, please comment or give this issue a
First of all: thanks for MockK. I'm very happy with it. I hope it will continue to add value to the Kotlin community.
Also, please note that I know you've commented on many issues already that your time is limited for good reasons. I think it's most important that you decide for yourself when to do what with your time. Please never change that.
Now the feedback: I noticed that it's been quite quiet around MockK's developments. It's been more than half a year since the current latest release (v1.9.3) was released, while previous releases happened on about a monthly basis. In the mean time some developments have taken place: new issues and PRs were opened, addressed and closed for various things. You introduced a stale issue management bot to help you prioritise open issues. But it all went a little bit slower than before, which I understand considering that you only have 24 hours in a day to spend on whatever you decide is important. I like MockK a lot and therefore it's a pity that so little (visible) development happened since the last release. Also, the developments on the Kotlin language and official stdlib extensions, like coroutines, continue to move forward. I'm afraid MockK will lag behind at some point. And in general, I wonder what's going on with MockK and where this project is going. Therefore I want to ask you to clarify the following questions.
What plans do you have for MockK? What do you need to keep actively developing on / maintaining MockK? Do you still want to be this project's lead developer? Do you need more time/motivation? Do you need maintainers? Do you need anything else?
Please, see this issue as a central place where you give the MockK community feedback about what you want, what you need, or whatever ideas you have. Or maybe ask whatever questions you might have yourself.
I'd love to help by working on MockK myself, but I think I neither have the time nor the required skills for it.
What might be a bit of motivation is the upcoming KotlinConf: wouldn't it be awesome to have some new features/bug fixes done in time for the conference, so that it's clear that MockK is still a valuable contribution to the Kotlin community? Please let the community know what you need to make this happen. I think we all want the same? Please let the community know how we can get there.
Happy MockK is growing and helping people.
Currently, my interest is shifted.
I would be happy to have somebody else regularly committing to MockK. Or even collect some money and hire somebody. I put a banner in regards to sponsorship on the main page for this purpose. Believe more user community grows more chances this is going to happen.
The biggest problem I see is that most of the issues appearing right now are corner cases and require a lot of effort to fix, great effort to learn for newcomers and usually don't give a lot of benefits. That's why it is hard to devote time and find somebody who helps to fix something. The codebase itself is pretty complex.
To some extent refactoring is possible, but generally, there are a lot of complex things happening under the hood. I tried to record YouTube videos to describe tricks on the way, but after a few realized it is not the best approach.
I also tried to engage people to tell what's complex they face while trying to fix something, do PR. Generally, belive a simple outcome is that wrongly picked up task may become a nightmare to implement.
For example, the issue with infinite recursion in ConcurrentHashMap actually may result in creating a copy of a series of JDK classes as a solution. You need pretty big courage to come up with this and some knowledge to implement.
That's why the first thing to do is to create a system of task/issue/bug categorization and categorize tasks. Maybe write for each issue it's prototypical solution.
I'd also like to help keep the project active, as I think it's a very valuable tool for the whole kotlin community. I can start lending a hand on the easier stuff while I get more accustomed with the codebase, so yes, I agree that categorizing tasks may be a good start to facilitate contributions.
Let us know how we can help :)
@oleksiyp this is a complex situation for MockK.
It's only logical that while the project progresses towards a more and more feature complete product, the issues that are left implicitly become more complex and/or are about edge cases. They're harder to diagnose and fix.
This might be a sign that it's time to think about what the lib's client API and the developer's maintenance API (code base) look like?
Another practical question:
Let's ignore the existing 'edge case' / 'complex' issues. What if new issues arise because the Kotlin language evolves (e.g. new releases with new features, or current features being deprecated/obsoleted)? Do you think you can make time to support Kotlin language changes when necessary?
I checked all opened issues(around 44) and added them to the following projects:
Beleive the next version should focus on the first category.
There are as well 77 issues filtered out by stale bot: https://github.com/mockk/mockk/issues?q=is%3Aissue+sort%3Acomments-desc+is%3Aclosed+label%3Astale