Future of argos discussion (co-maintainer, maintenance-only)
ElijahLynn opened this issue · comments
Per #106 (comment):
I don't use GNOME Shell anymore. I switched to Sway a while ago and have not looked back since. Therefore, Argos is in maintenance mode as far as I'm concerned.
And #106 (comment) by @real-or-random:
Do you think it makes sense to add a big "maintenance mode" notice to the README? Maybe it's possible to find a maintainer.
Let's discuss the future of argos here, some possible options:
- Add a new co-maintainer, solicit candidates
- Do nothing - Would lead the community to choose a fork to be new upstream and possibly have to change the name for license compatibility (would require package manager updates)
@p-e-w Do you have any opinions on what you would like to happen to the future of argos?
Thank you for starting this discussion. The question is not only who will maintain Argos in the future, but whether it can be maintained at all in the long term. The GNOME developers have made it crystal clear through their actions over the past years that they
- are unwilling to provide any stability guarantees for the GNOME Shell API, even between minor releases.
- consider it acceptable to break every single GNOME Shell extension on every single GNOME Shell release (this was in fact the default for the first few years of GNOME 3's existence, and has in practice continued because of massive API breaks in almost every release).
- consider less than two months from an initial pull request that introduces such an ecosystem break to its public release in GNOME Shell to be sufficient, with no outreach or deprecation period whatsoever.
- are willing to make not only breaking API changes, but changes that break the API so completely that it is not possible to write code that works both before and after (ES6 classes).
- might occasionally let multiple months pass before approving extension updates submitted to the official extension repository (happened to Argos in 2018).
For all practical purposes, GNOME Shell development operates as if extensions, and the people who make them, do not exist. Argos calls itself a "GNOME Shell extension", but in reality there is no such thing. There are only "GNOME Shell 3.30 extensions", "GNOME Shell 3.32 extensions" and so on. An extension that works with one Shell version may or may not work with another, and there is no way to tell without trying to run it on the other version. I estimate that at least 80% of extensions in the official repository do not work with the current GNOME Shell release.
GNOME is probably the most polished desktop environment ever created, and the only one with a singular, coherent vision. Unfortunately, it has been obvious for a while now that extensions are no longer part of that vision, if indeed they ever were. After nearly a decade of GNOME Shell, you still can't even update an extension without using a crappy browser plugin. Shell extensions are dead, they just haven't noticed it yet. I sincerely wish it were different, but the facts permit no other conclusion.
That being said, if someone else believes that Argos would be a worthwhile experiment to continue, I am willing to lend them my (limited) support towards that endeavor. In particular, I am willing to add (one or preferably multiple) collaborators to the Argos repository. If you are interested, please announce yourself in this thread.
On a somewhat unrelated note, it appears that BitBar, the macOS application Argos was inspired by and is compatible with, is also unmaintained, with just 4 code commits since 2016. Of course, Apple understands that if you want people to develop for your platform, you can't break everything every six months, so BitBar nevertheless still works with the latest macOS version.
@p-e-w ,thanks for your answer and your work.
I agree with all the points you write in your comment. After having used KDE for a while I really appreciate the polish and the coherency of Gnome.
But the management of its extensions is really disappointing, because they are indispensable to have a full featured desktop but also nearly unmaintainable due to the lack of consistency in the API.
I think that's confirm , in some points, the creator's of the cinnamon desktop and their vision
Is there maybe another approach like being compatible with BitBar and Argos but provide the same functionality for GTK(?) but outside of the GNOME Shell. That would of course require a new implementation but could achieve two things:
- Get rid of the GNOME Shell problems
- Create an actively maintained project
Is there something like this already? Would it be feasable?
I think we should at least maintain a repository where compatibility fixes such as #106 and #111 are merged. As long as there are incoming PRs for those issues, that makes sense and works for some people. Maybe it makes sense to have separate branches for the few last major versions.
I think the question is if @p-e-w's statement is still true:
I will continue to review and merge pull requests, and occasionally release a new version on extensions.gnome.org.
(see #75 (comment))
If he can confirm this, then it's possible to do this in this repo, which would be the cleanest. Then we should do some testing on older versions to help him make sure that these PRs can be merged or simply merge them only in specific branches.
The statement quoted by @real-or-random is still true, but I'm simply at a loss for what to do right now. GNOME Shell 3.36 isn't even released yet, but people are already expecting Argos to support it. But the fix (#111) most likely breaks Argos on all previous versions of GNOME Shell! It's a complete disaster, once again.
What I will emphatically not do is turn this repository into a mess of Shell version-specific branches. That would be the definition of "unmaintainable" for me. Then fix "W" is supposed to go into branches "X" and "Y", but not into branch "Z". That's kernel-level maintenance complexity, which is simply ridiculous for a damn desktop plugin.
But as stated before, I am open to adding additional collaborators to this repository. If they feel up to the task of keeping Argos working across multiple Shell versions, they are welcome to try. By myself, my informal policy is to merge a fix when I believe that the majority of GNOME Shell users require it. For GNOME Shell 3.36, that is not yet the case.
Hoping this fits in this thread :
AFAIC I was using GNOME only for Argos. Making menus that easily was so convenient. Before that I was using i3 with py3status to make my own widgets but they were not full menus and it was way harder to design. Now that Argos is broken I just don't have any reason to use GNOME anymore and I switched to Sway. Now I am looking for a menubar for sway which can handle GNOME-like menus (and not simple widgets) and as simple as Argos (and if possible, Argos syntax compatible to be able to use my scripts).
@raspbeguy
Argos is STILL running !!!
You can use the master version for gnome < 3.36 and the patched one for gnome 3.36. The only boring issue, is the log flooding by Js warnings.
It occurs on every refresh of the scripts you use.
For me, as I'm mainly using Argos as a fast customizable menu, I changed the refresh rate to 24 h and there is no more flooding.
For sure it's a rather "unstable" solution... but it works as it for me
Not sure I want to bother using a non-master version of it.
But as stated before, I am open to adding additional collaborators to this repository. If they feel up to the task of keeping Argos working across multiple Shell versions, they are welcome to try. By myself, my informal policy is to merge a fix when I believe that the majority of GNOME Shell users require it. For GNOME Shell 3.36, that is not yet the case.
I'm willing to help by managing and testing PRs. The issue is that I don't want to do this alone, my JS experience is pretty limited. Is there somebody else willing to help? Then we can split the work better and it's less effort.
We will see if I think different branches are a good idea. I think we should try at least something in this direction. It fits the model on extensions.gnome.org. I think we could restrict ourselves to fix only critical issues on older versions (that should basically never happen), no backport of improvements or normal bug fixes but tell people to wait for their GNOME update. This model seems to to work for other extensions: JasonLG1979/gnome-shell-extension-mpris-indicator-button#30 (Then we don't really need branches for older versions unless we have a critical issue, but also they won't hurt.)
Supporting a bunch of different versions will make you go crazy. Over the past few years that I have been an extension dev I've found what works for me is to basically do a rolling release on top of the most current version of GNOME Shell. I don't do releases other than what gets pushed to the extensions site. I only support the most recent version from the extension site and git master. (which are never ever far off each other) As far as git goes, I only have a master branch.
As far as dealing with breakages between versions. GNOME Shell releases shortly before Ubuntu and Fedora, so generally I'll fire up an alpha or beta of both of those in a VM and fix whatever is broken.
I try to be zen about it. I can't really remember a release that didn't break something. I just accept it. The lack of an API can be frustrating but I like to think that it means that there are no rules. It's a double edged sword.
@p-e-w, being one of the co-maintainers of the hamster shell extension, I feel your pain.
What I will emphatically not do is turn this repository into a mess of Shell version-specific branches. That would be the definition of "unmaintainable" for me. Then fix "W" is supposed to go into branches "X" and "Y", but not into branch "Z".
For the hamster extension, we came to the opposite conclusion. Creating a branch in git is a trivial and quick operation. The "mess of branches" isn't so bad after all, if development work focuses almost entirely on adaptations for new GNOME releases (which means that "fixes" basically only go into the master branch). Thus, for hamster, we basically follow @JasonLG1979's approach, keeping the option for branching open if it might become necessary in the future (e.g. for an urgent security fix).
Maintaining a single code base that works across all GNOME releases is impossible, AFAICS. An even if I'm wrong, compatibility code would be messy and hard to read. At any point in time, there are active Linux distributions shipping at least 4 different GNOME versions. If you don't take compatibility patches for the newer versions, "branches" will emerge in the form of forks, which is worse. It gets really bad if other people start uploading forks to extensions.gnome.org. It has happened to hamster, and we're still working to clean up the confusion.
I've come up with an argos version that supports GNOME 3.26-3.36. It can be inspected here. I believe GNOME < 3.26 is supported as well (or could be with minor fixes), but I haven't tested anything below 3.26 so far. Note that the code linked contains some other, unrelated fixes as well; details in the commit list.
It turns out that, for argos at least, making these backward-compatible changes is not that difficult after all. To achieve my goal, I had to sacrifice the clean object-oriented structure in menuitem.js (the constructor function is defined outside the class body). The main problem is the different object initialization between GObject classes and plain ES6 classes. I personally believe that that's worth the broader GNOME shell support that my changes provide. The overall function and readability of the code is not affected.
I've deliberately not created a PR for the p-e-w/argos repo, because I don't want it to look as if I wanted to take anything of @rammie's merits (#111).
Comments and suggestions for improvement are highly welcome.
That's a great news !
I've posted an issue yesterday because the version I was using was definitively not compatible with Gnome 3.36.2 (updated a few days ago)
I'll test it right now.
Many thanks
I've tested it on 3.36.2 and it does nothing.
I've no icon in the top panel
more details on the following post
Am I doing wrong ?
What Gnome version do you use ?
Thanks @mwilck, glad you are trying to keep this awesome extension alive
it worked well for me on 3.36.1
It was working for me on 3.36.1 version too, but not on the last 3.36.2 version.
The code can't be simply patched because the removal of the AltSwitcher object in the latest gnome extension API has a deep impact on the implementation used by p.e.w.
I'll try to do my best to code a new version as fast as possible, but I've plenty of things to do and gnome extension development lacks of support and documentation for a beginner in that domain.
Strange, AltSwitcher seems to have been removed in 3.35.2 already - 147a743d8d79 ("system: Replace action icons with regular menu items"). How is it possible that this was regression in 3.36.2 for you?
@LaurentOngaro, have you tried simply copying the removed AltSwitcher code to the argos code base?
I know that's strange because it was running for me on version 3.36.1
Perhaps I make something wrong.
But I've tested nearly all the version mentioned in this thread without success.
And, whatever, the AltSwitcher method is not in system.js anymore.
Perhaps the gnome shell was using a kind of binding or kept this code alive until now.
I've tried to make the smallest possible changes to the argos code and even to add the missing method, but the system.js file has heavily been changed, so I failed.
My knowledge of Gnome extension development was too light until now, but I'm currently trying to improve this skill
Strange,
AltSwitcherseems to have been removed in 3.35.2 already - 147a743d8d79 ("system: Replace action icons with regular menu items"). How is it possible that this was regression in 3.36.2 for you?
Moreover, how was it possible that argos worked for me with this removal if it occurred in 3.35.2 ?
Strange,
AltSwitcherseems to have been removed in 3.35.2 already - 147a743d8d79 ("system: Replace action icons with regular menu items"). How is it possible that this was regression in 3.36.2 for you?Moreover, how was it possible that
argosworked for me with this removal if it occurred in 3.35.2 ?
Maybe the AltSwitcher issue was a Red Herring. I had no argos scripts using alternate=true. I added one now, and it did not cause argos to crash or not run at all. Just the "alternate" functionality (i.e. the Alt key) didn't work.
I've pushed two more commits to my GNOME-3.36-compat branch to fix the AltSwitcher issue mentioned above.
thanks Martin, I test it right now.
I did not use alternate too, But I see no other issue in the log that can explain why argos does not work on 3.62.2 version
IT WORKS again !!!
the log is clean, no longer warnings
I've made a deeper test
The strange point is that I'm used to use a symlink for the script loaded in Argos in ~/.config/argos since months, and now it's not longer working with this method
When I replace the symlink by the script is was linked to, Argos works again.
Issue solved, many thanks
@mwilck Can you PR mwilck#1 here? I believe this could be merged here because it's strictly more compatible than the existing code.
That's a step at least. @mwilck Then with that contribution, can you imagine becoming a co-maintainer here?
Personally I still stick to what I said:
I'm willing to help by managing and testing PRs. The issue is that I don't want to do this alone, my JS experience is pretty limited. Is there somebody else willing to help? Then we can split the work better and it's less effort.
@mwilck Can you PR mwilck#1 here? I believe this could be merged here because it's strictly more compatible than the existing code.
OK, will do. @rammie has had 3 months to respond to my comment. Give me a few more days, I'm currently busy with other stuff.
@mwilck Then with that contribution, can you imagine becoming a co-maintainer here?
Not sure. AFAICS it would be sufficient if any active maintainer was willing and able to review and merge PRs once in a while. Is there anyone with respective rights to the repo except @p-e-w himself?
OK, will do. @rammie has had 3 months to respond to my comment. Give me a few more days, I'm currently busy with other stuff.
Ok, sounds good!
By the way:
because I don't want it to look as if I wanted to take anything of @rammie's merits.
What I usually do in this cases is to acknowledge co-authors in the commits. GitHub will then display authorship correctly: https://docs.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors
@mwilck Then with that contribution, can you imagine becoming a co-maintainer here?
Not sure. AFAICS it would be sufficient if any active maintainer was willing and able to review and merge PRs once in a while. Is there anyone with respective rights to the repo except @p-e-w himself?
As far as I understand #108 (comment), he's the only one with the permissions now and that's one of the issues but he's open to adding more maintainers.
I just wanted to post this blog post about Gnome extensions: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-rebooted-initiative/
I'm hopeful something good will come out of it and help with maintaining Argos.
I just wanted to post this blog post about Gnome extensions: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-rebooted-initiative/
I'm hopeful something good will come out of it and help with maintaining Argos.
Thanks for that article! Been reading through it and am watching this Gnome Extension BoF "A better extensions experience: extensions rebooted - Sriram Ramkrishna" > https://www.youtube.com/watch?v=pC5im1QDNKI.
Thank you for starting this discussion. The question is not only who will maintain Argos in the future, but whether it can be maintained at all in the long term. The GNOME developers have made it crystal clear through their actions over the past years that they
- are unwilling to provide any stability guarantees for the GNOME Shell API, even between minor releases.
- consider it acceptable to break every single GNOME Shell extension on every single GNOME Shell release (this was in fact the default for the first few years of GNOME 3's existence, and has in practice continued because of massive API breaks in almost every release).
- consider less than two months from an initial pull request that introduces such an ecosystem break to its public release in GNOME Shell to be sufficient, with no outreach or deprecation period whatsoever.
- are willing to make not only breaking API changes, but changes that break the API so completely that it is not possible to write code that works both before and after (ES6 classes).
- might occasionally let multiple months pass before approving extension updates submitted to the official extension repository (happened to Argos in 2018).
For all practical purposes, GNOME Shell development operates as if extensions, and the people who make them, do not exist. Argos calls itself a "GNOME Shell extension", but in reality there is no such thing. There are only "GNOME Shell 3.30 extensions", "GNOME Shell 3.32 extensions" and so on. An extension that works with one Shell version may or may not work with another, and there is no way to tell without trying to run it on the other version. I estimate that at least 80% of extensions in the official repository do not work with the current GNOME Shell release.
GNOME is probably the most polished desktop environment ever created, and the only one with a singular, coherent vision. Unfortunately, it has been obvious for a while now that extensions are no longer part of that vision, if indeed they ever were. After nearly a decade of GNOME Shell, you still can't even update an extension without using a crappy browser plugin. Shell extensions are dead, they just haven't noticed it yet. I sincerely wish it were different, but the facts permit no other conclusion.
That being said, if someone else believes that Argos would be a worthwhile experiment to continue, I am willing to lend them my (limited) support towards that endeavor. In particular, I am willing to add (one or preferably multiple) collaborators to the Argos repository. If you are interested, please announce yourself in this thread.
On a somewhat unrelated note, it appears that BitBar, the macOS application Argos was inspired by and is compatible with, is also unmaintained, with just 4 code commits since 2016. Of course, Apple understands that if you want people to develop for your platform, you can't break everything every six months, so BitBar nevertheless still works with the latest macOS version.
K, so just watched the video of the the brand new effort called "The GNOME Extensions Rebooted Initiative". This effort is aiming to solve most of these issues you mentioned that make it difficult to maintain Argos.
I am inspired enough to get involved with the local dev process effort and see where that leads.
Links:
- https://gitlab.gnome.org/World/ShellExtensions/extensions-rebooted (Main repo page, I did need to register)
- https://gitlab.gnome.org/World/ShellExtensions/extensions-rebooted/-/wikis/home (Extensions Rebooted Wiki)
- https://gitlab.gnome.org/World/ShellExtensions/extensions-rebooted/-/issues (Extensions Rebooted Issue Queue)
- Gnome Matrix channel for real time discussion (https://gnome.element.io/)
- https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-rebooted-initiative/ (Sri's blog post, same person who made the video below)
- https://www.youtube.com/watch?v=pC5im1QDNKI This talk ends with "Join us and let's end this destructive conflict" ~ Sri; Sri also said he is looking to get a hold of extension maintainers and mentioned it is a hard group to get a hold of, so if interested.
I am inspired enough to get involved with the local dev process effort and see where that leads.
So, @ElijahLynn, are you saying that you'll be forking argos soon and maintain it? That would be great news!
I am inspired enough to get involved with the local dev process effort and see where that leads.
So, @ElijahLynn, are you saying that you'll be forking argos soon and maintain it? That would be great news!
Not anytime soon. But eventually I could see that if I carve out enough time for this.
@mwilck Can you PR mwilck#1 here? I believe this could be merged here because it's strictly more compatible than the existing code.
OK, will do. @rammie has had 3 months to respond to my comment. Give me a few more days, I'm currently busy with other stuff.
Pinging @mwilck . I think this PR would be very helpful.
Just bumping the discussion. We are already in April 2021 and I still had to download a forked version to get it to work in Ubuntu 20.04. It seems to work well and per the discussion above could indeed be merged.
Is there a "forked version" which works with current gnome version (40)?
@p-e-w are you still interested in maintaining/co-maintaining argos? and if not, wouldn't it be more fair to state that explicitly and allow people to fork the project with clear conscience? (and if there is a communication going on via backchannels, can we please have some updates on where the things stand?)
Apologies for being slow to respond. The past few months have been a very difficult time in my personal life, and admittedly Argos (a project I don't use myself anymore) has been quite low on my list of priorities.
I just merged #127, the culmination of a combined effort by @mwilck, @jefferyto, @michel-slm, and @rammie. Since those four individuals clearly care about keeping Argos working, I would like to hereby offer each of them co-maintainership and write access to the Argos repository.
So, if you are either one of the individuals named above, or have otherwise contributed to Argos in the past, or have a proven track record maintaining other GNOME Shell extensions, and want to help ensure Argos has a future, please clearly state in this thread that you would like to be a maintainer. I intend to add 2-3 people as collaborators on this repo so the community can move Argos forward without relying on me. I will also look into how access to the extension listing on extensions.gnome.org can be shared, so co-maintainers can publish new releases through the channel that most people install Argos from.
The past few months have been a very difficult time in my personal life
🤗
@p-e-w, thanks a lot. I wish your personal life will get better / back to normal soon.
Everyone please note:
- My interest is to keep argos working the way it used to, e.g. adapt to GNOME shell API changes, and not feature development or other larger endeavors,
- I'm not a seasoned JS developer by any metrics,
- I can't guarantee response times below (say) a month,
- I have a very limited set of working environments in which I'm able and willing to do testing, basically only openSUSE (Tumbleweed and latest Leap).
My contributions as a "maintainer" will be contrained by the above points. If that's understood and accepted, and if there's at least one more person who accepts co-maintainership, I'm in the team.
They did it again 😠
The highly-appraised GNOME 42 release again requires changes to the argos extension to make it work. I have created #134, which seems to work for me so far. But this time we can't keep compatibility with GNOME shell versions that don't understand ES6 class syntax (GNOME 32 and older).
Tests of #134 with other GNOME versions would be appreciated.
Tests of #134 with other GNOME versions would be appreciated.
- worked fine on Arch with gnome-shell 41.5
- also fine on Arch with 42
Thanks!
Thanks @mwilck for your work.
If that's understood and accepted, and if there's at least one more person who accepts co-maintainership, I'm in the team.
Just pinging here in the hope somewhat steps up. (I know I said I'm happy to help but this was two years ago and I'm too much overwhelmed with other open-source work already, sorry.)
My contributions as a "maintainer" will be contrained by the above points. If that's understood and accepted, and if there's at least one more person who accepts co-maintainership, I'm in the team.
I'd be willing to co-maintain this with you under the exact same points.
How important is it that we keep compatibility to GNOME Shell <= 3.32 in the main branch? Even the pretty ancient openSUSE Leap 15.3 has GNOME 3.34 already.
Given that the current package on extensions.gnome.org supports 3.14-3.32, it might be ok to just submit a new version supporting 3.34-42. @p-e-w, I suppose you would need to do that after merging #134, or we need to figure out a way how other people could submit updates to e.g.o.
How important is it that we keep compatibility to GNOME Shell <= 3.32 in the main branch?
If I understand it correctly, there's no need for it, at all.
The web interface on e.g.o lets you install older versions anyway. For example, the oldest gnome-shell version supported in the current master is 3.26, but users can install argos for 3.14:
Right. If we could upload the patch set from #134 just for GNOME 3.34 and newer, users would be fine. This has has always been the case.
However, previous discussion here (#108 (comment) and follow-ups) showed that people strongly dislike the idea to have to maintain different branches for different Shell versions. That was my main motivation to try to come up with source code changes that would allow supporting 3.36 without breaking compatibility with older Shell versions, which was fixed by others and eventually merged. With the changes that became necessary for GNOME 42 support, this won't be possible any more (at least I can't see how).
Luckily, the code that supports GNOME 42 works all the way down to 3.34, which was released in September 2019. So the situation is different than in the past. In April 2020, support for GNOME 3.32 could hardly be dropped, but dropping it now (from master) doesn't seem unreasonable.
Since most of the maintenance effort now is adapting the extension to each new version of GNOME Shell, I think having version branches is scalable (and preferable). If there was still new feature development (and new bugs) this would be different, but once the extension is "stable" for the current version, it's basically done.
Furthermore, in order to minimize the maintenance effort and be somewhat close to upstream's velocity, I think only the current version of Shell and the latest LTS versions for each major distro should/can be supported (again, preferably in different branches).
(Apologies for not chiming in sooner - I would be happy to help when I can but I don't think I can commit to co-maintainership at this time 🙏)
More bad news I'm afraid: The updated version of Argos with #127 merged was rejected by the extensions.gnome.org reviewers because of code that
- has been in Argos since 2016
- wasn't touched at all by the update
- is also contained in the three Argos releases currently distributed by EGO, which remain approved(!)
I had a discussion with some reviewers on their Matrix channel, and additionally they voiced general security concerns about Argos' ability to run arbitrary code upon executable files being placed in its config directory (the core function provided by Argos). I debated this for a while but the conversation didn't really go anywhere, and I have no idea what changes are "required" to get the working version into the EGO store.
This is all just so very disappointing. It's bad enough that almost every GNOME Shell release breaks everything, but now it seems I have to deal with Apple/Google style gatekeeping on top of that. Argos is the 5th most popular GNOME Shell extension on GitHub. If this was Apple or Google, making sure such a high-profile app continues to work would be a priority for them. But the GNOME maintainers not only couldn't care less about the entire ecosystem being forced to chase an ever-changing API, they see no problem in rejecting an update because they suddenly realized that code that passed their review process on 3 previous occasions and has been on their platform for more than 5 years might run afoul of one of their vaguely-specified rules.
I really don't know how to move forward here anymore. I create open source software to provide value for others. The amount of disregard I have received from the GNOME platform in return for my efforts is absolutely disheartening (they have broken Plotinus as well, with no meaningful recourse).
Hello @p-e-w, thanks for your efforts and sorry to hear these frustrating news. I've tried to read the chat history but couldn't make Element show the history.
Just in case you still have some willingness left to continue the discussion:
- The security concerns are IMO real, and all argos users should be aware of them to some degree. Some discussion about possible improvements in this area would be worthwhile. I can imagine some additional checks, e.g. argos asking for explicit confirmation before executing a newly encountered script, or even some sort of sandboxing. Anything like that would be a new feature requiring considerable development efforts though; currently I don't see anyone who'd be willing to spend that effort. I wonder if short-term it'd be an option to pop up a warning for new users when argos is installed for the first time (e.g. suggest to keep the argos config dir read-only and double-check 3rd party scripts carefully before installing them).
- I can see that GNOME guys would be concerned about
eval()in particular, because bad or just buggy code in aneval()d script would cause the shell itself to crash or even act maliciously. I for one only use shell scriptlets. I have no experience with JS scripts and can't judge whether executing them withnew Function()as suggested by the GNOME people, would make lots existing scripts JS useless. Perhaps others would like to comment? - OTOH, shell extensions themselves pose a similar class of security risk as argos scripts. The e.g.o "review" process is basically the only hurdle that would stop users from installing malware into their desktop environment with a few mouse clicks. Maybe they realized this just lately and are therefore taking a more defensive attitude now. Ironically, by rejecting argos, they are forcing more users to install un-reviewed extensions…
- Maybe the welcome script can actually be dropped? On startup, we could simply check whether the argos directory is empty, and if it is, send the user a notification with a link to a "getting started" page?
- Wrt shell versions, I've had to drop support for GNOME shell < 3.34 in #134 anyway. I tend to agree with the GNOME people that loosing support for older versions isn't that bad, as 3.34 has been out for more than 2.5 years (see above), and users of older shell versions could continue with previously released argos packages (especially there haven't been any late feature changes). Dropping
Langshould also be possible.
@p-e-w
I share your sentiment, this seems unreasonable...
I really don't know how to move forward here anymore.
I believe a first step would be to make @mwilck and @sthesing co-maintainers (see a few comments above). This will make sure they can ensure compatibility here (even if not on extensions.gnome.org), and this would give them the authority to talk to the reviewers further, if they're willing to do so.
- The security concerns are IMO real, and all argos users should be aware of them to some degree.
a) First of all, the review just talks about chmod +x, and I think this could be solved if they insist.
b) Are GNOME Shell Extensions safe? mentions only malicious code in extensions. The code in the extension is not malicious. The concern is that it makes the system more vulnerable.
c) But even if this concern is a relevant criterion for the review, I don't see a real security problem when it comes to executing scripts: If you assume the attacker can write to files in the argos directory, or put executables (+x) files there, then it can most likely write to (large parts) of your $HOME directory, and find many many other places to insert malicious code, e.g., bashrc just to name one.
double-check 3rd party scripts carefully before installing them)
I agree users should to this, but this is not mainly the responsibility of this extension. So if users can be tricked into installing malicious script, they can probably be tricked into executing them (without moving them to the argos directory). I agree a warning would be helpful. But I feel it's orthogonal to the concerns brought up by the reviewers and I think those should be addressed first.
Maybe the welcome script can actually be dropped? On startup, we could simply check whether the argos directory is empty, and if it is, send the user a notification with a link to a "getting started" page?
To be honest, I think this would actually be better in terms of user experience. I was somewhat "surprised" by the welcome script, and a "getting started" page may be better. (I guess we can all agree that such a page is not tremendously worse, and if it address the main concern of the reviewers, then it would be an easy way to move forward... 🤷 )
I agree a warning would be helpful. But I feel it's orthogonal to the concerns brought up by the reviewers and I think those should be addressed first.
Ack. If it's really just about chmod +x, we could drop that without loosing much.
b) Are GNOME Shell Extensions safe? mentions only malicious code in extensions.
That was my point wrt eval() above. By running eval() on arbitrary JS code in the context of an extension, we obviously circumvent any security guarantee that the upstream review could provide. From that PoV it's understandable that reviewers don't have much love for it.
If users can be tricked into installing malicious script, they can probably be tricked into executing them
Right. Argos just adds one more "attack vector", no more and no less. And indeed, it's orthogonal to the review process. My thinking was that in the review discussion, we might be able to convince reviewers by showing that we understand the concerns, and deal with them in reasonable ways.
I have somehow managed to overlook @sthesing's above offer to co-maintain with @mwilck. My apologies for that.
@mwilck, @sthesing: I have invited both of you to become collaborators with write access to the Argos repository. You have my permission and encouragement to commit and merge PRs as you see fit in order to keep Argos up to date with the GNOME Shell API, add new functionality to Argos, or make any other changes that benefit Argos.
I just want to address two of the points that have been brought up above:
The security concerns are IMO real, and all argos users should be aware of them to some degree. Some discussion about possible improvements in this area would be worthwhile. I can imagine some additional checks, e.g. argos asking for explicit confirmation before executing a newly encountered script, or even some sort of sandboxing.
It's clearly documented in the README that Argos runs executable files that are placed in its config directory. That's simply the core functionality of Argos, and I consider this an important part of the "smooth" experience Argos provides. Hot reloading combined with file monitoring makes for an amazingly fast iterative development process. I wouldn't want to give that up.
Adding a confirmation prompt before running plugins is a bit like adding a confirmation prompt to a shell, asking whether you really want to execute the command you just entered. Executables don't get placed in the Argos config dir by accident. Within the context of Argos, placing them there means that yes, I want to run them. Blindly copying an executable into the config dir is like blindly copying some random text into a shell prompt.
As for a malicious actor placing executables there, this was brought up by a reviewer on Matrix as well, and it's the argument that convinces me the least. Such a malicious actor would already need write access to the home directory, at which point you're completely compromised almost by definition, especially on a desktop system. The .bashrc example given by @real-or-random is exactly what I told the reviewer in question during our discussion.
Maybe the welcome script can actually be dropped? On startup, we could simply check whether the argos directory is empty, and if it is, send the user a notification with a link to a "getting started" page?
The idea of the welcome script is to have a menu appear immediately after installing Argos to make it clear the installation succeeded, while providing a live example of how an Argos plugin looks like, and giving the user the ability to open the welcome plugin's script file for editing with a single click, in order to start experimenting with their own functionality right away.
I carefully designed that experience for minimum onboarding friction and instant enjoyment. I don't think opening a web page would provide the same quality of experience, where you then need to manually open a text editor, manually copy & paste some code, manually save the file to the config directory, and manually make it executable, just to see your first plugin appear.
@p-e-w: fair enough. I am not questioning your design decisions. Just thinking aloud how we might be able to come to an agreement with the reviewers.
@mwilck, @sthesing: I have invited both of you to become collaborators with write access to the Argos repository. You have my permission and encouragement to commit and merge PRs as you see fit in order to keep Argos up to date with the GNOME Shell API, add new functionality to Argos, or make any other changes that benefit Argos.
I'm not sure whether I'm still the right person to help maintain this project in the current situation. I offered it out of interest to keep Argos usable for as many people as possible, as I am relying on it, myself. Frankly, it's the only reason why GNOME is still usable for me.
So my interest was to keep Argos available through EGO. But since that is now... difficult...
I'm sorry, but I have neither the will nor the necessary expertise to argue with GNOME developers about whether or not Argos is a security risk or whether it is acceptable under their terms.
I hate to chime in after so much discussion has already happened, but can someone summarize the future of this Argos extension? As I understand it, there are a couple of PRs that will fix the extension for GNOME 42, but one of them needs to be rebased to p-e-w/master, and I'm unsure of the status on the other, but I believe it has issues that cause GNOME to stutter & hang. I also think I've seen in the (Issues or PRs) that the main sticking point for getting a working release out is that the GNOME developers that review extensions (for extensions.gnome.org) have pushed back against the extension, citing security issues for the scripts.
So, I guess I'm asking -- is this extension now dead? Is there a functioning branch for 42, even if I'm pulling from github (or the AUR, btw) rather than the extensions.gnome.org website?
It's sad that the gnome devs don't want it to be on the official site.
But the typical user of Argos is the type that would be fine with running a few gnome-extensions commands.
So for now the simplest recourse would be to ignore the existence of extensions.gnome.org and do what many linux utilities do: have a file you download from github releases with install instructions in the readme.
If you want I can try to help with a github actions workflow to create a packed extension file that will run when a release is created and attach it to it (I'm comfortable with github actions)
I think having users install this extension outside of the "normal" extension installation process would lead to an even worse user experience than having a confirmation window. Users would have to repeat the (manual) process for every update.
I don't think a confirmation dialog is necessarily a bad thing. People rarely read documentation or READMEs. dconf Editor has one:
Firefox has something similar for about:config as well.
I agree with both of the posts above -- I think that a short-term github release "this fixes Argos for Gnome 42" would be fine for most Argos users, but I also tend to think that Gnome devs are pushing toward a larger vision (a Gnome eco-system?) and having Argos on the extensions.gnome.org website is pretty important for usability, security, etc. For instance, I use APKs I get from F-Droid, but I'd never expect my parents to use F-Droid, so the Google Play Store is more appropriate for them. I see github as F-Droid, and e.g.o as the Play Store. For mass adoption, I think Argos should try to stay on e.g.o.
If a simple "here be dragons" warning pops up when you enable Argos, I think that's a pretty small price to pay for continued adoption. But, if more involved fixes are required (manually select the scripts from Argos options?) then obviously, that'd be a case-by-case basis.
But your parents are probably not hacking together scripts they want argos to run ;)
For instance I just put together my own Zoho Books timer. What sort of non-hacker needs argos?
In any case it's certainly ideal to get it uploaded but my point is the alternative is not complete death. To your point, there are lots of things on fdroid
your parents are probably not hacking together scripts they want argos to run ;)
Thankfully, no!
What sort of non-hacker needs argos?
I think there are lots of use cases that are non-hacker, but easier than writing a full Gnome extension. My immediate cases:
- a system monitor that shows exactly what I want, like backup status on a remote server (kinda hacker)
- a stock ticker (not too hacker)
- a microphone kill-switch (I could 100% see non-hackers wanting this, especially these days)
So, I'm not disagreeing too fervently, I'm just saying that if Argos can stay on the e.g.o site by making a few concessions, then I think it would be advantageous. Plus, automatic updates are nice, even for hackers like us, right?
In any case it's certainly ideal to get it uploaded but my point is the alternative is not complete death. To your point, there are lots of things on fdroid
Agree here 100%
I don't think we're disagreeing at all then. If someone has energy to figure out how to make gnome devs happy and implement it, power to them, but if not, or at least until then, having manual install instructions is totally fine, and providing a packed extension file is nice, and that could be done by CI.
There will be no user-visible changes to Argos for the sole purpose of getting the extension into EGO. No confirmation dialog, no removal of the welcome script, absolutely no departure from how Argos looks and feels today. This is non-negotiable.
It's cool that EGO exists, and if they want Argos in their repository, I'm happy to have it there. If they have certain technical requirements (manifest files, usage of certain APIs etc.), I'm happy to make the changes necessary to fulfill them. But under no circumstances am I willing to change what Argos does for the privilege of having it listed in someone else's software store.
If I was OK with an unaccountable cabal deciding what my software may and may not do, I would write for the iOS and Android app stores instead, where there is a vastly larger audience and even realistic monetization opportunities. Free Software isn't a "nice to have" for me, it's the reason I write software in the first place. I'll be damned before I let anyone else tell me what my software is "allowed" to do. If they want to be gatekeepers, I'll stay outside of the gate. Anyone who has a problem with that should simply fork and rename Argos.
so i think that hard fork is now not only years overdue, but also required; rationale below:
@p-e-w, the primary issue – as i see it – is that you don't have a problem with gate-keeping per se, the problem you seem to have is that you want to be the sole gate-keeper for the application.
…and being a gate-keeper is the only role you're recently fulfill:
- you can't be bothered with providing a governance structure for argos, despite seeing the need of it,
- you can't be bothered with providing code updates,
- you can't be bothered with timely responses to pull requests
ultimately, the effect of your gate-keeping is to deny any user experience to people who are not you, while you don't even use the extension yourself.
the primary issue – as i see it – is that you don't have a problem with gate-keeping per se, the problem you seem to have is that you want to be the sole gate-keeper for the application.
You mean I want to prevent low-quality code and functionality that I oppose for ideological reasons from entering an application that has my name attached to it?
You better believe it.
so i think that hard fork is now not only years overdue
Oh, go right ahead! As long as you make it clear that your repository is indeed a fork and I am not responsible for that particular version of the code, I have no problem with that whatsoever. Maybe you will actually succeed in reviving Argos. But from my own experience, I consider it more likely that you will find that:
- Maintaining this extension is a far more complicated and subtle task than it appears.
- Your issue tracker will be flooded with spam-like questions that have nothing to do with the extension at all.
- Code contributions you receive (if any) range in quality from OK-ish to abysmal (no offense intended to those who have contributed to Argos in the past). The review process to fix those problems takes almost as much effort as it would have taken you to write the code yourself. If you take the shortcut of ignoring quality issues and just merging whatever you get, the codebase will become unmaintainable very quickly.
- Even if you succeed in appeasing the GNOME overlords and get your fork of Argos published on EGO, there is no guarantee that your next update won't be rejected for reasons that sound like the reviewer just made them up. EGO doesn't have any objective rules for what is and isn't acceptable. You can then chase down decision makers on their Matrix channel and hope they actually make a decision, which they may or may not do.
- If you fail in any of those efforts, random people who never contributed anything to Argos will feel entitled to tell you and the community what "needs to happen"... just like you did in this thread.
Best of luck!
quod erat demonstrandum.
were you really interested in having the project survive your ego trips:
- you would move it into its own organization, so that your precious name don't get sullied,
- you would actively look for co-maintainers, preferably choosing them from the people who put the most work into keeping the code alive in the last few years,
- you would avoid awkward situations, where you offend potential and actual contributors and call it caring about the code quality.
instead of complaining about abysmal quality of contributions,
- you could provide a clear bill of expectations for a patch / pull request,
- you would communicate clearly your expectations as for the coding style,
- you could identify areas of improvement and carve out simple tasks to provide a way to onboard new contributors.
(etc., etc., there are good examples of more complex mutter extensions that went through the developer's burnout phase and survived by taking these steps)
instead, you're the very example of upstream developer downright hostile to both users and contributors to the project.
Can we please stop being cynical and personal? This isn't going to help anyone's case.
If someone (@jubalfh?) steps up with a fork, let's see how it goes.
if i was sure that i have enough time and resources to manage a project, i would do that gladly.
personal themes aside, i would still think that a single person owning the project (be it the original one or the fork) would be an unnecessary risk: burnout is a thing, communication with gnome maintainers is rarely frictionless and requires plenty of patience (on both sides), and a single person doing everything in a project is a recipe for disaster.
you will notice that most succesful gnome extensions outside the gnome repositories are either managed by a team, or have corporate backing; both allow to work around the burnout / tiredness issue.
were you really interested in having the project survive your ego trips [...]
[...] so that your precious name don't get sullied
I have zero tolerance for personal attacks. I am blocking you from all my repositories, and marking your hostile comment as abuse. Go away and stay away.
To everyone else, you are welcome to discuss this project's direction in a civil manner. If I see any more remarks like the above I will lock this thread.
Hi all,
Hope this is the right discussion to jump into. The version of this gnome extension at the gnome extension page is outdated. Could it be updated to the current master to have gnome 44 supported?
Would be great!
Regards,
Bas.
Unfortunately, this won't happen. See @p-e-w's #108 (comment) above.
Tnx for the update. Didn't read all the comments...
Sad to hear, but I understand the issue. Maybe it is better than to make this more clear on the extension page and here.