Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New maintainer #767

Open
ZimbiX opened this issue Jan 17, 2023 · 17 comments
Open

New maintainer #767

ZimbiX opened this issue Jan 17, 2023 · 17 comments

Comments

@ZimbiX
Copy link
Collaborator

ZimbiX commented Jan 17, 2023

Hi, it looks like this project could do with a new/additional maintainer? I'd like to offer my assistance =)

There are several issues and PRs I'd like to see completed, plus a bunch of cleanup of the issue backlog.

@ZimbiX
Copy link
Collaborator Author

ZimbiX commented Jan 18, 2023

It's hard to see who could even approve this =P

Ping @chrisspen, @paradoxxxzero, @darkxst

CC @glerroo, @mgalgs, @franglais125, @DevDef, @shemgp

@mgalgs
Copy link
Collaborator

mgalgs commented Jan 21, 2023

Hi @ZimbiX, thanks for taking the lead on this. I can't live without this extension, which is why I've been maintaining my fork (and associated extension listing, system-monitor-next). The original goal of system-monitor-next was simply to get releases cut sooner, but the apparent abandonment of this repo has forced me to start taking actual patches over there as well.

I hope one of the admins can add you as a maintainer soon. In the meantime, I'm going to pull the changes that you've recently reviewed here into system-monitor-next.

@ZimbiX
Copy link
Collaborator Author

ZimbiX commented Jan 21, 2023

@mgalgs This extension is similarly invaluable to me! (And indicator-multiload previously, back with Unity when I started using Linux as my primary OS on Ubuntu 12.10).

Good work with the -next idea given the state of things. Once I have access, I'd like to do a release after each merge (with a safety net of more thorough automated testing on recent versions of Gnome Shell); which would make a -next extension unnecessary.

Although if I can't get added soon, we'll have to think about moving to a fork. Would moving to your extension/fork and using it as the primary repo be a good idea? The reason I'm thinking that may be preferable is to automatically carry forward as many users as we can, if possible. But the name 'system-monitor-next' wouldn't be so applicable at that point (and paradoxxxzero's being an irrelevant namespace in [email protected]) - can an extension be renamed? That is, on the GNOME Shell Extensions website, the namespace in the filesystem, GSettings, etc. Given 'system-monitor' is taken, what would be an appropriate new name? Or if we use a new namespace, would it be alright to keep the name the same? Maybe it's just a lot simpler to start fresh with a new listing on the GNOME Shell Extensions website, and add a message on the others? So many questions 😅

@chrisspen
Copy link
Collaborator

If the build doesn't pass, I typically won't act on it, and most of the builds have been failing for a while. However, I see you submitted a fix, so I'll go through them and see if that clears up some of the backlog.

I have a very busy day job, so I don't have a lot of time to devote to fixing the build. I spent a lot of of my own time and money setting that up, so this project would have a little bit more stability.

@ZimbiX
Copy link
Collaborator Author

ZimbiX commented Jan 21, 2023

Thanks for the reply, @chrisspen! <3

If the build doesn't pass, I typically won't act on it, and most of the builds have been failing for a while

Fair enough. Though as you've seen, there was what looked like a fix submitted three months ago (not by me, but I reviewed it). If it doesn't work, and you don't have time to sort it out yourself, I'd appreciate a pointer in the right direction =)

I'll go through them and see if that clears up some of the backlog.

Cheers! 🙏

I have a very busy day job, so I don't have a lot of time to devote to fixing the build.

No worries - I expected you were just busy.

I spent a lot of of my own time and money setting that up, so this project would have a little bit more stability.

Oh, what cost money? Is this on a paid Travis plan?

So are you open to passing the baton / sharing the maintenance burden?

@ZimbiX
Copy link
Collaborator Author

ZimbiX commented Jan 21, 2023

Oh wow, I had no idea Travis was no longer free! Sounds like we should look into an alternative. I love Buildkite, but you have to supply your own hardware and has limited minutes. GitHub Actions is probably the go these days.

@mgalgs
Copy link
Collaborator

mgalgs commented Jan 22, 2023

GitHub Actions is probably the go these days.

I've been using Github Actions for automating submitting the extension to gnome in my fork and was planning on porting the Travis tests to GA soon (hopefully tomorrow along with the pending patches here).

https://github.com/mgalgs/gnome-shell-system-monitor-applet/tree/master/actions

I'm not sure on the rename... I believe a new uuid would require a new listing on the extensions website, which would be kind of a bummer since -next has picked up a ton of new users recently with the lack of gnome shell 43 support here...

@chrisspen
Copy link
Collaborator

Oh, what cost money? Is this on a paid Travis plan?

Because I was short of time and had already spent a ton of my time setting up a build that could run an Ubuntu desktop (something that turned out to be substantially non-trivial), I paid someone on BountySource to finish writing the Dogtail script that actually tested accessing the applet.

Travis has changed some of it's terms because they have bills to pay, but as I understand it, for us it's still free.

@chrisspen
Copy link
Collaborator

I'm not strictly against moving to a different build platform. But I don't think it would necessarily be cost effective. It was a huge effort to get the build working in Travis, and I've setup enough Github CI builds for other projects that I know configuring an Ubuntu desktop Docker build for Github would also be a massive pain. Each system has their own quirks and limitations that take a while to sus out.

It was working on Travis, and although it's currently broken, my intuition says it'll be a lot easier to fix that than move to a completely different environment. It would only make sense to leave Travis if they insist all open source projects have to pay or they drop Docker support or some other critical feature we need.

@ZimbiX
Copy link
Collaborator Author

ZimbiX commented Jan 22, 2023

Thank you for merging all the green PRs. Are you doing a release as well?

I kindly ask you for the third time to please respond to my key question: Are you open to adding me as a maintainer?

@chrisspen
Copy link
Collaborator

I'm going to give it a week or so for the authors of the remaining 3 PRs to respond, as well as let people test master, now that all the fixes are in. After that, assuming everything looks good, I'll do a release.

As for being a maintainer, if you mean someone who can merge to master or perform releases, I don't have access to give you that permission. Only paradoxxxzero can do that. Even if I could, I'm not sure it would be a good idea having multiple people merging things to master or doing releases. However, you're being a huge help reviewing PRs and giving feedback. You don't need any extra access to do that.

@ZimbiX
Copy link
Collaborator Author

ZimbiX commented Oct 17, 2023

I feel it important to bring up this topic again given the inaction, number of open PRs, and the breaking/significant changes required to get the extension working on Gnome 45. See #795 and mgalgs#38. Gnome 45 is now also used in Ubuntu 23.10, released a few days ago. The situation of maintaining this extension is getting further out of hand, with merge conflicts mounting, contributor passion waning (in at least myself), and the '-next' fork continuing to diverge through necessity to keep things functioning.

I'm not sure it would be a good idea having multiple people merging things to master or doing releases

I've never had issue with this before. If you foresee some, we could work out an agreement of how to operate to avoid stepping on each other's toes.

As for being a maintainer, if you mean someone who can merge to master or perform releases, I don't have access to give you that permission. Only paradoxxxzero can do that.

I will reach out to @paradoxxxzero directly to see if he can grant me that permission; and the permission to grant it to other key contributors like @mgalgs.

@ZimbiX
Copy link
Collaborator Author

ZimbiX commented Oct 17, 2023 via email

@sidt4
Copy link

sidt4 commented Oct 17, 2023

I love this extension, and it's the first extension I install on my GNOME installations. Much thanks and appreciation to the core maintainer(s), devs and all contributors involved.

But, as we can see, as for any GNOME extension, this extension needs much needed attention and maintenance, and if the current maintainers(s) have the bandwidth to address them, it would be really great.

But, if that's not possible for whatever reason(s), it would be nice to make it clear, so people who have the willingness and ability to take the extension forward can decide on the next steps. And, if someone is willing to share / take that responsibility of maintaining this extension, the current maintainers(s) should evaluate the proposal and communicate their thoughts on this.

@scr4bble
Copy link

One is wondering whether the main owner is alright (being able to respond). I guess you should set some deadline guys and then make the decision. This is an issue already for a looong time so I guess "end of 2023" sounds legit. For me maybe even sooner.

Btw. thank you very much for all your work - to both original maintainers and the new contributors that care about this extension to survive. I will be watching this issue and I am already jumping to the new fork from @mgalgs - if no cummincation happens here, staying on the fork and abandoning this repository.

@paradoxxxzero
Copy link
Owner

Hi there,

Very sorry for the long silence and the state of this repository.

I finally took the time to investigate what's happening here and @ZimbiX you are right, the -next fork should be upstreamed and the actual active developers should manage this project along with motivated people.

As a start, I granted @ZimbiX and @mgalgs collaborator rights here, so @mgalgs can merge back its fork if it's still possible and @ZimbiX can work on PR and Issues if it's not too late.

Thanks for your interest in this piece of code and sorry for being scarce here.

@darkdragon-001
Copy link

darkdragon-001 commented Nov 20, 2023

@paradoxxxzero thanks for the update and granting collaborator rights to more people.

We should also think about creating a GitHub org which is owned by all the maintainers together instead of relying on a single person. It's possible to move repositories in which case GitHub creates redirects such that people still having the old location will find the new one.

AndrewKvalheim added a commit to AndrewKvalheim/nixpkgs that referenced this issue Dec 1, 2023
The upstream source has been unmaintained and is currently incompatible
with GNOME 45. Per discussion in paradoxxxzero/gnome-shell-system-monitor-applet#767,
maintenance is expected to resume, but during the interim the most
usable source is the fork mgalgs/gnome-shell-system-monitor-applet.
@ZimbiX ZimbiX pinned this issue Apr 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants