Skip to content
This repository has been archived by the owner on Sep 8, 2020. It is now read-only.

Is this project maintained? #992

Open
afontenot opened this issue Mar 26, 2020 · 28 comments
Open

Is this project maintained? #992

afontenot opened this issue Mar 26, 2020 · 28 comments

Comments

@afontenot
Copy link

I want to emphasize right at the outset that I don't believe project maintainers have any kind of obligation to the community to continue working on a project. I'm very grateful for htop and all the work that has been put into it thus far.

I was recently surprised to notice that there haven't been any new commits to the project in over a year, and issues and pull requests are piling up. One in particular I'd very much like to see merged, adding support for PSS: #843

If the maintainer no longer has time or interest in working on the project, would they support additional community involvement, or possibly even a community supported fork, in order to get issues quashed and pull requests dealt with? I don't have the skill to do that, personally, but as htop is one of the most widely used sysadmin tools, I'm sure people would step up.

If this is just a temporary slowdown in time to work on the project, I'd be happy to hear that too! Thanks again for htop!

@Jesin
Copy link
Contributor

Jesin commented Mar 30, 2020

I have wondered about this for a while now. My pull request #917 is a simple 1-line fix for a leak of FILE objects. I have been using a version of htop with that patch applied since I submitted the pull request 9 months ago. I've also applied #981 since then. htop is still by far the best program for its job that I have ever encountered, and I'd like to thank the old maintainer for all their work on it. I also would like to know if they're OK, if they have any plans to continue maintaining it, or if we should find a new maintainer.

@etosan
Copy link
Contributor

etosan commented May 14, 2020

Maybe contributors with most patches accepted could step up and then try to approach Hisham? His activities bar is mostly green, maybe he doesn't have time anymore?

@polluks
Copy link

polluks commented Jul 14, 2020

Maybe we should switch to https://github.com/XPhyro/htop-xphyro?

@DarthGandalf
Copy link

Or any other of the 604 forks here: https://github.com/hishamhm/htop/network
There are updates in some of them in June and July

@natoscott
Copy link
Collaborator

Maybe we should switch to https://github.com/XPhyro/htop-xphyro?

This fork (or a fork it forked from?) seems to have changed the license from GPLv2 to GPLv3, despite the original htop license being GPLv2-only.

@natoscott
Copy link
Collaborator

Or any other of the 604 forks here: https://github.com/hishamhm/htop/network

Would anyone else be interested in forming a group of maintainers? (rather than just a 1-person model)
I see someone (?) recently created a https://github.com/htop but did nothing with it so far.

I'd like to go through the Linux distro bug-fix patches and get them merged at least, and then complete the 3.0.0 release that @hishamhm started some time back...

$ git tag -l | tail
2.0.0
2.0.1
2.0.2
2.1.0
2.2.0
3.0.0beta1
3.0.0beta2
3.0.0beta3
3.0.0beta4
3.0.0beta5

... but I don't really want to be the only person working on this.

@polluks
Copy link

polluks commented Jul 15, 2020

@DarthGandalf Well, not everyone who forks or commits wants to be a new maintainer.

@fasterit
Copy link
Collaborator

@hishamhm any comments?
TBH, I for my side would much prefer you to either continue maintaining htop yourself or accept a few co-maintainers into this repository.
I'm not to keen on competing patch queues and volatile upstreams.
DLange
(Debian maintainer of htop)

@etosan
Copy link
Contributor

etosan commented Aug 3, 2020

@natoscott - so do you consider yourself committed enough to lead group of alternative maintainers?

Maybe we should try friendly fork approach for some time and reach hishamhm later (for resync)?

@natoscott
Copy link
Collaborator

@etosan yes, I guess so. I tried contacting @hishamhm by email a couple weeks ago without reply.

My preference like everyone here I think would be to be sending PRs to Hisham, but if that's not an option I can take this on for now. I'd be more than happy to hand it back to Hisham if he has time for it in the future.

Is there anyone else available to help with maintenance? I'll attempt to make contact with github to find the person behind https://github.com/htop next and see if we can use that (still seems to be unused).

@fasterit
Copy link
Collaborator

fasterit commented Aug 9, 2020

@natoscott I tried to contact @hishamhm from the Debian side multiple times as well.

I don't know why we don't receive a reply and what the underlying issue is as he is frequently active in his business projects (which are hosted on Github as well).
So at least he's alive and working, which is good to know.

So - with the same reluctance that you express - @ginggs and me (DLange) are willing to support the fork. Getting /htop would be good to reduce the confusion that will happen for some time about what the "canonical" (sorry to Red Hat :)) upstream is.

@natoscott
Copy link
Collaborator

| So at least he's alive and working, which is good to know.

Yep, good to know - that's the most important thing.

| I'll attempt to make contact with github [...]

I've heard back from github - they say the "github.com/htop" account is indeed active, its just not publicly visible activity (presumably a paid account) - so we cannot use it.

In light of that news, I've gone ahead and registered the "htop.dev" domain and started setting up "github.com/htop-dev" starting from the last code and docs from @hishamhm ...

https://htop.dev
https://github.com/htop-dev

I've also done an initial review of the last ~2 years worth of pull requests. There are approximately 50 PRs(!) that are good candidates to be merged - clear bug fixes, and simple-or-in-demand features . :| I'll start working my way through those next.

| Is there anyone else available to help with maintenance?

@fasterit does "willing to support the fork" mean help with maintenance or mainly switching over to it in Debian? (i.e. do you want / need write access to the repo for development work?)

Is there anyone who has spent some time in the htop code and wants to specifically help maintain it? (respond to PRs, issues, etc). There must be folk who were involved in the various platform ports, at least ...?

Let me know and I'll start adding people into the organisation - I'm hoping to avoid the situation that if I can't keep it going in a few years for some reason that it stalls again.

@fasterit
Copy link
Collaborator

I've also done an initial review of the last ~2 years worth of pull requests. There are approximately 50 PRs(!) that are good candidates to be merged - clear bug fixes, and simple-or-in-demand features . :| I'll start working my way through those next.

Awesome, thank you very much!

| Is there anyone else available to help with maintenance?

@fasterit does "willing to support the fork" mean help with maintenance or mainly switching over to it in Debian? (i.e. do you want / need write access to the repo for development work?)

Yes, please add @ginggs and @fasterit to htop-dev. We should clean up the backlog first and then think about a new release.
If that turns out well, we'll package it for Debian and that way switch upstreams. Still not happy with this but it seems we have no better choice right now.

@natoscott
Copy link
Collaborator

Yes, please add @ginggs and @fasterit to htop-dev.

Done.

We should clean up the backlog first and then think about a new release.

+1 - since @hishamhm had created 5 'beta' tags for htop-3.0.0 already, I expect the first task will be to merge clear bug fixes, release 3.0.0 in a few weeks maybe (?), then circle back and (re-)consider feature work for subsequent releases.

Still not happy with this but it seems we have no better choice right now.

Agreed.

@gaod
Copy link
Contributor

gaod commented Aug 18, 2020

I'll keep contributing Ubuntu ppa & FreeBSD ports with new upstream.

@natoscott
Copy link
Collaborator

@gaod great - I've added you too. There's also a new #htop freenode IRC channel for discussion and coordination of our efforts. Please feel free to join us there!

@maxiberta
Copy link

Will switch the htop snap to the new upstream - edge channel first, then candidate and stable on next major release (3.0.0?). Thanks! o/

@bertwesarg
Copy link

maybe announce your maintenance effort on the ML: htop@freelists.org

@natoscott
Copy link
Collaborator

maybe announce your maintenance effort on the ML: htop@freelists.org

Good idea - mail sent now - thanks.

@hishamhm
Copy link
Owner

hishamhm commented Aug 29, 2020

Hi everyone!

First of all, I want to say I am really happy with this development! This is truly FOSS working as intended.

Second, with that out of the way, I want to apologize for being unresponsive. After almost 15 years maintaining a piece of software by myself (with an amazing number of community contributions, of course! but carrying the maintainer burden on my own (and this is the not only project I've been maintaining mostly single-handedly for over 10 years)), one which started as a hobby and a learning experience, I gradually drifted away from it — the project felt pretty much "done" for my own use, and expanding it towards other horizons (such as the next branch in this repo) would be another mini-project in itself, that I kept meaning to get to it "one day".

At one point I realized that I had spent several months without looking at the "htop" folder in my mail client, and it felt like taking a sabbatical. At that point I thought, "well, that was refreshing": in the meantime I was able to branch out to new projects and new ideas (which I really want to be able to carve out time to explore!). I quickly looked at the state of htop repo, saw the mounting PRs... thought myself, at least there are no critical bugfixes like the macOS craziness I've had to deal with in #682 (wow, 2018! I guess that was one of the last things I did here). That macOS bug which was very symbolic of the type of maintenance work I had to deal with in htop at that point in time: bugs for other platforms, new features for machine configurations I can't test... you know, maintainer chores. Then I looked at the beta branch with unfinished work, sighed, and I thought "yeah, I'll get back to this some time". And then months flew by again.

During that period, the thought of handing over maintainership crossed my mind many times (as recently as last week, incredibly!), and I always thought "ok, but to whom? how do I go about this?". And then today I wake up to the news of htop 3.0.0, which I got via Twitter! And I must say, my immediate reaction was of relief.

I guess here it's a good point to make a note that might be useful for others: yes, burnout is a very real thing and for FOSS maintainers it can be hard to identify. I've experienced burnout at work before, and it's easier to spot — because of the performance pressures — and to deal with — because ideally you have a supportive organization around you. For FOSS maintainers, the best-effort nature of the endeavor in most cases may make it hard for you to measure that effort, to balance your sense of duty to a community (that at times you built yourself!) to that of the effect it has on you (as in "why did I start doing this in the first place"). If you find yourself looking at your own FOSS projects and sighing, I guess that's a sign!

Yes, it was reckless of me to have filtered all mail mentioning "htop" email to a folder (I realized that for LuaRocks I have different filtering rules where Github/mailing list/etc go to a folder but direct messages go to my inbox — that would have been a better idea!), and not looking at it for so long. I apologize to @natoscott and @fasterit who tried to contact me; I understand that forking the project must not have been an easy decision to make, and any response of mine might have made it a little easier.

I want to thank you all of you for taking on this initiative, starting from @afontenot for opening up this topic. I am extremely grateful for all the amazing feedback I've received for htop over the years. This has been by far my most successful project, it has brought me many many great things, and I think it's indeed flattering to see it forked — I remember now saying once in a discussion about FOSS that "if something is unmaintained and important enough, it will be forked". I guess this means htop is in a sense important enough to someone, and I'm honored for that. As I said above, that's FOSS working as designed. I'm certain I could have handled things better from my side, but I guess all's well that ends well!

I'm excited to see the project move forward, and I'm making myself available for any administrivia you folks would like me to do in the transition process (such as getting this repo transferred, so this one auto-redirects and the issue and PR history gets preserved, making the original website redirect to the new one (love the domain!), etc).

Thank you all once again, and here's to htop's future! Cheers!

@fasterit
Copy link
Collaborator

Thank you very much for the positive feedback, @hishamhm. We're happy you are healthy and have had very understandable but not critical reason for going under cover some time. And we are even more happy Twitter got you noticing us. That's probably the best thing Twitter has done, ever :).

I'll ping you next week and see whether your mail filter is a bit more gentle now :-). Have a great weekend!

@slacka
Copy link

slacka commented Aug 29, 2020

@hishamhm
For the sake of the hundreds of Linux distros that use this package, could you kindly consider either

Either will greatly benefit users and maintainers of smaller distros. Continuing the development in its original location would be ideal as no work would be necessary for users or distro maintainers. Thanks for all you have done!

@DarthGandalf
Copy link

I think instead of 'closing' it it should be transferred there, to preserve numbers of old issues/PRs.

@fasterit
Copy link
Collaborator

I'm confident @hishamhm, @natoscott, @ginggs and myself can come up with a useful transition plan.

@netstx
Copy link

netstx commented Aug 30, 2020

@hishamhm obrigado!

@josteink
Copy link

josteink commented Sep 1, 2020

What I e done in the past, which I think has worked out well is to create a GitHub organisation for the project, and transfer the project-ownership to that.

And then provide the new maintaner(s) with full access within that organisation.

It will ease all kinds of administrative tasks, and providing adequate access to new contributors (or maintainers!) will be much easier, and much less breaking to the outside world. It also makes Github provide automatic redirects for people still using the old URL for the repo.

My 2 cents.

@franciskim
Copy link

@josteink yup, I agree and that allows you guys to take sponsorships as well

@Martin-Eckleben
Copy link

@hishamhm Thank you very much for all your hard work!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests