search

cjbassi / gotop

A terminal based graphical activity monitor inspired by gtop and vtop
GNU Affero General Public License v3.0
7.39k stars 444 forks source link

REQUEST: Add maintainers & remove deprecation #187

Open xxxserxxx opened 4 years ago

xxxserxxx commented 4 years ago

I mentioned this in #154; I'm making this a separate ticket so that it can be discussed.

I'm asking for two items:

  1. To be made a maintainer of this repository
  2. To remove the "no longer maintained" header on the README

I believe your repository has value for distribution packagers, and would like to retain the repo. I'll maintain and develop it, and work through the pull requests.

At the very least, please either accept or reject this ticket, so that I can make progress. If this package is no longer maintained, I'd like to work with distribution managers to switch to a fork that is maintained, and for all of the people who have been requesting merges.

Thanks.

xxxserxxx commented 4 years ago

Some of you have pull requests going back to April of last year. Any of you who are interested in talking about governance of the project, please ping me. In case Caleb has disappeared, I'd like to have some consensus on a new authoritative fork and proceed with getting distribution packages moved over and merges accepted.

Personally, on my fork I've been going through and doing some code re-organization, and I've added dynamic layouts.

asciicast

cmatsuoka commented 4 years ago

Hm, it seems that I forgot to send the final parts of my PR. Too many things to do I guess. Please allow a few more days so I can sort this out and submit what's still missing in #135.

xxxserxxx commented 4 years ago

@cmatsuoka , I don't know whether Caleb is accepting pull requests. He's marked this project as unmaintained, and hasn't made any code changes (including merging pull requests) since July of last year.

I spent some of today merging pull requests into my fork, but until we hear back from @cjbassi (or it becomes obvious he's not going to reply), it's safest to go ahead and submit the pull request to this repository.

EbonJaeger commented 4 years ago

You know that all work on this is happening in his other version in Rust, right? As unhandy as it is to have to migrate to a different project for distro packaging..... grumble grumble

xxxserxxx commented 4 years ago

Yes, I'm aware that all of Caleb's work is happening in his other project. I'm sure some (many, most, a few) developers will also decide to contribute to that project as well. That's an entirely different project, though, with a different name. Since I won't be contributing to a Rust project I'd like to keep gotop alive.

I don't see a conflict. If Caleb has moved on to a different project, that's fine. One way or another, I'm going to keep gotop going. I'd prefer to keep it in Caleb's repository, to preserve all of the meta-history (issues, package maintainer links, etc), but if I have to continue it in a fork I will.

EbonJaeger commented 4 years ago

Just making sure. :)

I would think that the normal thing to do would be to maintain your own fork. Seems to be what usually happens.

cjbassi commented 4 years ago

To clarify, I'm still around, I've just abandoned this project in favor of ytop and I've been working on it instead.

I get that there is some churn and disruption with migrating to a new project including for package managers, but that's a normal part of a software development and evolution. See Node -> Deno, Python2 -> Python3 etc.

For those that still want to use a version that's in Go, that's fine with me, but I would prefer if that was done as a fork. It sounds like @xxxserxxx has got something going already which is great, maybe I can add a link to it in the readme also.

xxxserxxx commented 4 years ago

Ok, thanks Caleb.

xxxserxxx commented 4 years ago

For those of you still wanting to use gotop:

I'm going to work on merging the rest of the outstanding requests. I restructured the project files to be more idiomatic with common Go layouts, so the merges will be unnecessarily tedious; that's on me so I'll do the merges. However, going forward, if anyone has any other changes they're thinking about doing, please make a clean fork of my project and issue your pull requests there.

I've started reaching out to the packagers about changing the upstream and maintainer information, and I'm looking into whether or not I can get the open issues pulled over. These constitute my top three priorities (pull requests, distribution packaging, and outstanding issues).

Aside from responding to questions here, I'm moving conversations over to the fork. Thanks, and for those of you who have long since stopped paying attention to the project, sorry for the noise.

howjmay commented 4 years ago

I am OK for any decision

jakesylvestre commented 4 years ago

@cjbassi, it might be a good idea to add a link go @xxxserxxx's branch (secondary, of course, to ytop). Our use case for instance requires gotop to be wrapped in an internal cli written in go and we couldn't use ytop if we wanted to. Just a thought

cjbassi commented 4 years ago

Just added it to the readme.

xxxserxxx commented 4 years ago

@jakesyl , would you mind explaining this a bit more over on the other repo? I'm not only curious, but if there's something I can do to make this easier -- such as factoring all of the code out of main() to make it more library-ish -- I'm quite willing to do that. Feel free to file a feature request if there's something that'll help.