python-diamond / Diamond

Diamond is a python daemon that collects system metrics and publishes them to Graphite (and others). It is capable of collecting cpu, memory, network, i/o, load and disk metrics. Additionally, it features an API for implementing custom collectors for gathering metrics from almost any source.
http://diamond.readthedocs.org/
MIT License
1.74k stars 601 forks source link

Concern around lack of activity #699

Open DStape opened 6 years ago

DStape commented 6 years ago

Hello @Gaurav Jain, @josegonzalez, @kormoc, @mattrobenolt, @mzupan, @rtoma, @shortdudey123 (I'm picking on you all simply because you're listed on https://github.com/orgs/python-diamond/people :)),

The last commit to land in this repo happened way back in May 2017, not far off a year ago.

The most recent release, 4.0.515, was made in November 2016, which was about a year and 3 months ago.

A backlog of issues and PRs have built up and it doesn't look like the majority of these have had a response from any of you guys.

Is there any particular reason for this? Should I start thinking about migrating to a different stats collector such as collectd?

I've enjoyed using diamond so far and it essentially does everything I need it to do. I recently put out #698 and I'm also looking at contributing a new Kafka handler, but I don't want to spend the time doing this if no-one's going to review my code.

I completely understand that you'll be working on many other projects, both open-source and for work (or a hybrid), I'm in a similar position, however if there's anything I can do in terms of helping maintain this code, I'd be happy to help, although with the main caveat being I'm more interested in the infra code, rather than any specific collector or handler.

Thanks, David

mattrobenolt commented 6 years ago

I personally have no capacity to contribute to Diamond. Primarily because I don't use it anymore as we have moved on.

josegonzalez commented 6 years ago

I honestly stopped watching the project. I have a ton of other OSS projects, but I also need to feed my cat so work gets in the way more often than not.

Many of the users seem to think that merging their pull request is simply just "clicking a button". Unfortunately, when there are tests, those aren't updated, and when there aren't, there are obvious breaks in functionality.

If you want to go through and test specific pull requests, ask for tests/docs/changes, and ping me on them so I can merge, great. I can't say I'll immediately get around to setting up releases, but I can probably take a look at it this weekend. I believe there are docs for that... somewhere, and it should be relatively easy to at least make it something we can do via a bash script.

DStape commented 6 years ago

Thanks for your response @mattrobenolt, that's absolutely fine.

On reflection of my original post, I think all I'm trying to determine is whether or not I should fork this and go my own way. I'd definitely prefer not to though, especially as there still seems to be a reasonable amount of interest in this project.

mattrobenolt commented 6 years ago

So to @josegonzalez's point, maintaining all of our plugins was a real burden. There's just so many different things and so much different software that Diamond can monitor, that it's unbearable to maintain in core Diamond.

A while back, I pushed to slim down core Diamond to essentially just basic system monitoring, and provide individual repositories for each plugin, so they can be maintained independently by people who have context, etc. But these efforts were stalled and there wasn't a ton of interest.

This would help make Diamond as a project more sustainable: https://github.com/python-diamond/Diamond/issues/183

With that said, I put in effort into getting the structure in place, as commented: https://github.com/python-diamond/Diamond/issues/183#issuecomment-223072250 with an example of splitting out the Redis collector.

DStape commented 6 years ago

@josegonzalez , OK, I think there should be some kind of contribution guide then, not something that has to be written from scratch, we can leverage one from some other project.

I'm happy to go through the outstanding issues and at the very least prod for additional info where it's needed. I'm not going to put a timescale on this though. I will ping you on the PRs that I think are 'merge-able', but feel free to disagree.

As for releases, I think that can come once the backlog of issues and PRs is dealt with.

DStape commented 6 years ago

Thanks for linking to that issue @mattrobenolt , I agree 100% that a new model is needed for how collectors and handlers are maintained, the possibilities for those are endless. I'll have a read over that and see if there's anything I can do to stir that into action (although I doubt it'll be an easy task).

(I'm signing off for the night but will follow up on this over the coming days.)

gaurav commented 6 years ago

I think you want @jaingaurav, not me. Removing myself from thread.

Raboo commented 6 years ago

Perhaps allow more people to become maintainers of this project? Ask people that sends pull requests. Look at forks with high activity, ask them to join and help instead of having a second maintained fork.

DStape commented 6 years ago

@Raboo , yep, I don't think forking is a good way to go and there still remains decent user activity on this project.

I have requested to pick up maintainership for the debian packaging side of things - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888077.

I've started going through the open issues (oldest first) and trying to determine the best/quickest way to resolve each. @josegonzalez , I've been tagging you in the ones I feel should be closed. Before I continue on with this, are you OK with me doing this? I don't want to be spamming you with unwanted emails.

My current plan of attack is as follows: look for issues older than 1 year that report problems/bugs with collectors/handlers that have no associated PR or suggested code changes. Reasoning behind this is as follows:

I don't think it's feasible to continue to maintain all of the collectors and handlers that exist today, at least not in this repository, they should be split out (somehow) into new repositories and new maintainership privileges given to those that are interested. Therefore, unless critical, I don't think spending time on old collector/handler problems is a good use of time.

My intention is to make multiple passes over the open issues so this is just the first iteration.

I'm interested in any feedback anyone has on this.

Thanks.

josegonzalez commented 6 years ago

Sounds good. Spam away and I'll try and get to closing when I see them.

Raboo commented 6 years ago

Well this is a bit of double work. @josegonzalez just add @DStape to this project so he can close issues and do some house cleaning. He's obviously interested in helping out.

josegonzalez commented 6 years ago

I will once I've seen that he continues to provide support/comments in the way he is committing to. I have no intention of being a blocker here. If any other maintainer wants to override and add, feel free.

Raboo commented 6 years ago

Okay, makes sense.

DStape commented 6 years ago

Thanks for your input @Raboo. And @josegonzalez, I'm happy with that, it makes sense to me too.

hslavchev commented 5 years ago

Did anything come out of this?

shiplu commented 3 years ago

The project still is not active!

@mattrobenolt If you have moved on, could you also tell what are you using for collecting stats?

Primarily because I don't use it anymore as we have moved on.

mattrobenolt commented 3 years ago

Datadog

mpcathey commented 3 years ago

What did everyone else switch to? :)

We're still using this project, but are exploring other options due to lack of activity...