REQUEST: Add maintainers & remove deprecation

[xxxserxxx]

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]

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.

• @BartWillems added the degrees symbol(°) to the temperatures, made the TempWidget.Draw function more flexible #184
• @howjmay fix: Fix typos #183
• @fleaz Add degree symbol to temperature values #177
• @jrswab Solarized theme fixes #179, Added sigterm options to "d" command. #168, Configuration File #167, Added a color scheme to match Nord. #166
• @theverything Add missing cli option to README and fix formatting #165
• @Kraust FreeBSD Fixes & Nvidia GPU Support #157
• @azak-azkaran Added Temperatures for Nvidia GPUs #156
• @mattLLVW Implement #148 and #149 #152
• @whuang8
• @rephorm Add support for filtering processes by substring. #147
• @Tazer #137 feat: added so we switch to static colors if there isn't enough … #140
• @cmatsuoka Add Linux console font #135

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

[cmatsuoka]

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]

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

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]

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]

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]

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]

Ok, thanks Caleb.

[xxxserxxx]

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]

I am OK for any decision

[jakesylvestre]

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

Just added it to the readme.

[xxxserxxx]

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