-
Notifications
You must be signed in to change notification settings - Fork 96
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
Maintainers needed #280
Comments
I hope I can help, what do you have in mind? should I just pick a random issue and try to solve it, do you need help reviewing the prs, writing docs? |
Hi, Thanks. |
👍 We've got a few issues outstanding. I'd say grab one and open a PR for it. Thanks for helping! |
on it :) |
Hi, I would like to help. Let me know about an issue to work. |
Hi, I'm interested in helping as well. There is a bunch of good work sitting on master. How can I help get us to v4.13? |
Let me know what needs to be done, would like to work upon it. |
If you want to help: Work on open issues: Review Pull Requests: |
Anyone want a release? Or plan what's next? |
Hi @bf4 , I'm still interested in the 4.13 release. There are fixes already on master that would be useful to me. Releasing just that would be awesome. Are there other things you'd like in this release? I looked through the tickets a bit this morning, and many of them are new feature work, or involve the online tooling (travis, launchy) which I'm not sure how to help with. #262 seems like a fixable bug; I could take a stab at that. |
Same, I'd love a release :) |
Having spent some time in the repo this evening I do have some interest in planning what's next. And what's next in my mind is nothing drastic, mostly just moving things forward to support the newest versions of ruby, and the newest versions of the metric tools. Tests passed in more recent rubies (2.3.x, 2.4.x, and 2.5.x). I think we could alter the Gemfile to be a bit more permissive about new ruby versions, locking down the gem requirements only for older constraints and being hopeful about the future. I'm also willing to through the issues and labeling them. |
Love the idea!
…On Tue, Feb 27, 2018 at 8:34 PM Andrew Nutter-Upham < ***@***.***> wrote:
Having spent some time in the repo this evening I do have some interest in
planning what's next. And what's next in my mind is nothing drastic, mostly
just moving things forward to support the newest versions of ruby, and the
newest versions of the metric tools.
Tests passed in more recent rubies (2.3.x, 2.4.x, and 2.5.x). I think we
could alter the Gemfile to be a bit more permissive about new ruby
versions, locking down the gem requirements only for older constraints and
being hopeful about the future.
I'm also willing to through the issues and labeling them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#280 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC-2J0aNJjrjxAZtOFALCnl7gJYsSDjks5tZK05gaJpZM4J__t9>
.
|
the alternative, is to sunset the project and recommend more active ones like pronto ( see https://github.com/metricfu/metric_fu/wiki/Code-Tools though I haven't updated it in a bit, the only new ones I can think of offhand are simplecov alternatives) If people are really gung ho on working here, and I started because it was fun, so that's enough of a reason, here's what I've been thinking of doing: simplify each piece by building multiple gems in one project like https://github.com/kaminari/kaminari
I had put a lot of thought and effort into making metric fu more modular but never finished. It should be pretty easy to break up metric_fu by components and make sure each is independent. This would also help you release changes for e.g. reek more easily Ultimately, what I would have liked to have done would be to promote a common interface for metrics tools to take in the ASTs generated by either ruby_parser or parser, so that you'd only have to parse once. I spiked some work in Reek to do this once, but it's gone now, and I think there's a PR or something for flay? |
Perhaps it is time to sunset this project and more actively recommend the
alternatives. I can't say I'm gung ho; spare time is hard to come by. I
have loved this project though. The nice wrapper around all these tools and
the continuity of this history charts were great. Thanks again for all your
work on this.
…On Thu, Mar 1, 2018 at 2:08 AM Benjamin Fleischer ***@***.***> wrote:
the alternative, is to sunset the project and recommend more active ones
like pronto ( see https://github.com/metricfu/metric_fu/wiki/Code-Tools
though I haven't updated it in a bit, the only new ones I can think of
offhand are simplecov alternatives)
If people are really gung ho on working here, and I started because it was
fun, so that's enough of a reason, here's what I've been thinking of doing:
simplify each piece by building multiple gems in one project like
https://github.com/kaminari/kaminari
- kaminari
https://github.com/kaminari/kaminari/blob/master/kaminari.gemspec
- kaminari-actionview
https://github.com/kaminari/kaminari/blob/master/kaminari-actionview/kaminari-actionview.gemspec
- kaminari-activerecord
https://github.com/kaminari/kaminari/blob/master/kaminari-activerecord/kaminari-activerecord.gemspec
- kaminari-core
https://github.com/kaminari/kaminari/blob/master/kaminari-core/kaminari-core.gemspec
I had put a lot of thought and effort into making metric fu more modular
but never finished. It should be pretty easy to break up metric_fu by
components and make sure each is independent. This would also help you
release changes for e.g. reek more easily
Ultimately, what I would have liked to have done would be to promote a
common interface for metrics tools to take in the ASTs generated by either
ruby_parser or parser, so that you'd only have to parse once. I spiked some
work in Reek to do this once, but it's gone now, and I think there's a PR
or something for flay?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#280 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADmmXpW1hv2HRF-AFJv0p4H4Q5f8h-sks5tZ55VgaJpZM4J__t9>
.
|
I'm also interested in this project - none of the alternatives seem to match up. What can we do to revive this codebase? |
I'm up to assist. What is needed? |
Hi @bf4 and all, I'm interested in co-maintaining I went ahead and submitted these PRs:
I'd love to get some feedback on those. 😃 |
sigh, sorry I'm not so present on this. Basically, before I give someone commit, I want to look at their code... and I haven't done much of the latter so I haven't done much of the former. Giving rubygems permissions for releasing new versions is more serious, so that'll take a little more attention on my part before I trust you enough :) |
Somebody (or a group of people) probably just need to fork this repo at this point. |
@jacobbeasley the issue isn't a need for a fork (though you're welcome to). If you can maintain it and are willing you, I'll give you commit. And if that looks good, I'll give you rubygems ownership. |
If anyone is interested, I started this fork: https://rubygems.org/gems/fastruby-metric_fu. It fixed #305 which is what was blocking me. |
Hello everyone.
Thanks to @bf4 and the maintainers of metric_fu in the past for the the work and the trust on us. I hope we can help keep moving the project forward. Please if you would like to help maintaining metric_fu contact any of @etagwerker or me thanks! |
No description provided.
The text was updated successfully, but these errors were encountered: