Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: what are the (near future) plans for MockK? #374

Open
erikhuizinga opened this issue Oct 27, 2019 · 9 comments
Labels

Comments

@erikhuizinga
Copy link
Contributor

@erikhuizinga erikhuizinga commented Oct 27, 2019

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 馃憤. Or otherwise let me know what you think.

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.

@oleksiyp

This comment has been minimized.

Copy link
Collaborator

@oleksiyp oleksiyp commented Oct 27, 2019

Happy MockK is growing and helping people.

Currently, my interest is shifted.
Although I am trying to follow what's happening.
If some major issue apear I will react(alike new Kotlin version incompatibility, JVM)

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.

@erikhuizinga

This comment has been minimized.

Copy link
Contributor Author

@erikhuizinga erikhuizinga commented Oct 27, 2019

The codebase itself is pretty complex.

That's an interesting fact. Would it be worth the effort to simplify the codebase, and would that help?

@oleksiyp

This comment has been minimized.

Copy link
Collaborator

@oleksiyp oleksiyp commented Oct 27, 2019

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.

@Raibaz

This comment has been minimized.

Copy link
Contributor

@Raibaz Raibaz commented Oct 28, 2019

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 :)

@erikhuizinga

This comment has been minimized.

Copy link
Contributor Author

@erikhuizinga erikhuizinga commented Oct 28, 2019

@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?

@oleksiyp oleksiyp changed the title Feedback: what are the (near future) plans for MockK? Discussion: what are the (near future) plans for MockK? Nov 2, 2019
@oleksiyp

This comment has been minimized.

Copy link
Collaborator

@oleksiyp oleksiyp commented Nov 2, 2019

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

@oleksiyp

This comment has been minimized.

Copy link
Collaborator

@oleksiyp oleksiyp commented Nov 2, 2019

Cross-referencing #356 . Don't hate bot 馃懠 After all, triaging 44 hot issues is kind of easier than 120

@oleksiyp oleksiyp pinned this issue Nov 2, 2019
@oleksiyp oleksiyp added the important label Nov 2, 2019
@oleksiyp

This comment has been minimized.

Copy link
Collaborator

@oleksiyp oleksiyp commented Nov 2, 2019

Triaged everything that was closed by stale bot.

Mockito https://github.com/mockito/mockito/issues has 230 opened issues which is 31%, while mockk has 82 opened issues which is 35%. So not everything is so terrible.

@Raibaz

This comment has been minimized.

Copy link
Contributor

@Raibaz Raibaz commented Nov 4, 2019

Thanks a lot for doing this, it's been very helpful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can鈥檛 perform that action at this time.