REQUEST: Add maintainers & remove deprecation about gotop HOT 13 OPEN

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.

from gotop.

I am OK for any decision

from gotop.

Just added it to the readme.

from gotop.

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.

from gotop.

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.

from gotop.

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 #184
• @howjmay #183
• @fleaz #177
• @jrswab #179, #168, #167, #166
• @theverything #165
• @Kraust #157
• @azak-azkaran #156
• @mattLLVW #152
• @whuang8
• @rephorm #147
• @Tazer #140
• @cmatsuoka #135

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

from gotop.

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.

from gotop.

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

from gotop.

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

from gotop.

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.

from gotop.

Ok, thanks Caleb.

from gotop.

@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

from gotop.

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

from gotop.