[Suggestion] Make repo for applets/desklets/extensions #6130
Comments
|
Plesse take note of mtwebsters comment here #4149 |
|
|
|
Yo @lestcape, do you think it would be feasible to implement github (or other git hosts) with the spices site such that one can install a theme directly from a git repo? Various plugin managers are doing this since ever. |
|
This is possible... But will be more complex, because the dev of the theme will need to take on account that his development site is now a source to install his theme for different incompatible versions of cinnamon... Some thing can be do if we used the release to specify a range of compatible version using some regular expression on the release task. But always will be required to follow some rules when you create your packages, Will not be possible reads all types of formats. In fact, configurable menu have the ability to read a format file on github and detected the last version of cinnamon installer and if is higher than the current installed version it throw an updater with the ability of download the last version of cinnamon installer and then install it in the user domain. Some similar things could be done, but as github it's not thinking for this, the most difficult part will be follow some package format. |
Why would that be difficult? One would just put a notice on the spices site on what your dir structure needs to look like to make your spice installable. |
|
@zagortenay333 true, i say will be possible, but yes also difficult, not impossible. Also why you say ony themes? this could included, extensions, applets, desklets, search providers, nemo extensions... |
|
Well I said spices, not just themes. 😄 But why would it be difficult? Github has a really simple and rich API: https://developer.github.com/v3/repos/contents/#get-archive-link The only thing that would need to be implemented is an option on the spices site to use a git repo instead of uploading a zip file, right? |
|
Probably yes, if you create your releases as a zip, with the same format as spices web sites. Also you can use the github api or not. It's not really necessary. But for example, if you have an applet in spice that have multi-versions inside and you have an applet in github with multi-version (you will need to create a way to download the correct version in the multi-version release or you will need to download all and then decide who version you will want to active). In this case when you want to install the applet, who applet will be installed? To select the applet to be installed you will need to provide more information in all of this releases that provide a way to selected the most convenient applet (a priority for the installation). This is just for mention one things... Another will be the speed... When you try to update the list of available "packages", there are not a thing like that... This will not be a problem for 3 or 4 applets, but for 100 applets, well... |
|
One can use branches if you want to work on multiple versions concurrently. That would be a pretty simple solution. If you prefer to use tags you could just specify that on the spices site. The list of available packages wouldn't change at all; you still have the spices site with all the package information as before. The spices site would just need to periodically check the git repos for updates and notify the user about an update (that notification feature would be really nice too). |
|
Yes, there are alternatives, but easy it's not. At less you need to do more things... Also on what you say, spice will not be another source more, as will be a source and also who really control the others sources internally... This probably will required more hardware than what spices have currently. Edit: Also someone will need to decide if a github repository could be added to the list of repositories or not, and this will not be a user decisions. In my point of view this need to be a user decision not a global decision. |
|
Hi, We'll be moving all spices to github very soon. We'll make announcements as soon as this is ready and explain how development and maintenance will work going forward. |
|
Please @clefebvre installations from github 😉 🙏 |
|
@lestcape The user gives the repo. The point is that instead of me uploading a zip, I provide the link to my repo. You keep saying it's not easy without explaining why it would be difficult.. |
|
Hi, I'll just give you the general idea but you'll need to wait a little bit for the fine details :) The idea is that all spices will be hosted on github by Linux Mint. The spices website will auto-pull from github so anything that gets merged onto the master branch will make its way towards the website and thus towards Cinnamon installations. We'll have teams, with the Mint developers but also with notorious spices devs and artists. We'll work via PRs. Mint's role will primarily be to review PRs for malicious code (i.e. security) and with a very laxist approach when it comes to functionality (typically if an author PRs his own spice, we'll just review from a security point of view and merge almost automatically). PRs from non-owners will need the author's approval. The Cinnamon devs will also be able to automatically fix regressions or add support in spices for upcoming versions of Cinnamon. Overall this will improve security greatly but also guarantee better working spices because users won't rely solely on 3rd party devs and artists to update their work, the Mint team will also be involved. |
|
If I take one of your themes as an example, technically it won't be "your" theme anymore. It will be hosted by us and you will need to PR it to update it. In practice you're still the author though, so any PR you make for it will be merged. PRs from other people will require your approval. The Mint team will intervene to fix issues or bring support. For instance, if this had been in place earlier, we would have added support for 3.2 in your theme automatically, even before 3.2 was out. |
|
In regards to teams we also want active artists and devs to join us, not only so that they can work directly on master without PRs, but also so that they can help in reviewing PRs for other spices. We'll create specific teams for the spices. |
|
So you're gonna fork all those spices? That's a lot of work 😮 I like the idea. Granted it isn't as automatic as my proposal (I'm a lazy ass 😄), but a heck of a lot better then the current situation. So where does the spices site fit into this? Will it be removed, or are you gonna implement github with it similar to what I suggested? (sorry if that belongs to the finer details hehe) |
|
@clefebvre good news, thanks for that. It not clear for me, but i think it's a good a big job. |
|
@clefebvre Oh, ok, good idea, I was wondering what that repository was for when you made it (I'm watching you on GH) |
|
@clefebvre It's what I've been waiting for. Thank you. Smart move. |
|
I have been waiting for spices to be cleaned up for a long time. Thanks for making it possible. |
|
ah :) |
|
@clefebvre how do you join the group of theme devs? also, just wondering, will all spices in the master branch be pushed automatically on all users? (ex. all cinnamon users will get a clone of the whole repo) |
|
@clefebvre I'm with @Elbullazul in wondering how... Also, by auto-pulled, does that mean whatever is on the spices repository is made into pull requests by the website that then get merged automatically? Or are they checked for safety first? |
|
Hi, We'll have more info on this when it is ready. Give us a week or so. The checks will happen at merge time, by reviewing PRs. The spices website will auto-pull from master. The interactions between Cinnamon and the spices website will remain the same. |
|
I hope this will be available soon. I want to remove my xlets from spices, but i can't do that right now because it's in migration. I dislike how this is implemented. I'm not working for organizations that recive donations. I'm development for users and without recive a donation. So, I will never push an update in this new github repositorie and i also dislike that some one push something with my name on this. If some one want to do that i have not problem with it. This is free software and always will be, but please not use my name, because i dislike that. I have not any problem to distribute MY WORK using several canals, What I dislike it's the intermediary github repository. This steals the credits of the develoment and confidence in my own products, in favor of the credits of Mint/Cinnamon. I'm not a cinnamon developer and i don't want to be one. I'm not developing things to be evaluated for others. When i want to do a thing like that, i create pull request in real cinnamon repositories, not in a place that it's my code, but it's not mine. Because this is by definition a develop for others. |
|
I'm with @lestcape, I don't like the idea of someone reviewing all I do. It would make me feel bad each time I upload something because I will know someone will have to work on it. And I'm of those who NEVER uploads just once because I always forget something. If it has to be in a git repo why can't it be downloaded directly from the owner's? If what you want is have all xlets working you can disable users from downloading them from the spices when they get outdated, or fork them if you feel like you want an extra. I think this is a bad idea a priori. |
|
The current state of spices is crap, at least 50% of the stuff there is broken! Fedora is sponsored by redhat and receives all it's infrastructure (web and hardware) from them.
|
|
Yeah, I don't like this at all. Not for me. 😞
|
|
@clefebvre thanks for the clarification, but I didn't mean the list of commits. I meant the commits themselves because they would be squashed into a huge one. Anyway I like to complain too much and I'm probably the least indicated to do so 😅. |
|
@clefebvre just wondering, will icon themes ever be supported by spices? I only see themes available, but icon themes have to be manually installed. some concerns I have:
Also, just a small note, the Chrome OS theme you credit to brahimsalem is actually mine: https://github.com/elbullazul/chrome-os |
You don't have to. Ideally when you fix something and you see the very same bug elsewhere, it would be nice if you could fix it in both places.. but if that's not your thing, that's ok too.
You don't have to either. It's a requirement to be delivered through the Spices website and the System Settings. If you can convince people to trust you directly (you've been making themes for a while so why not) and download your spices from somewhere else, then you can reach your audience directly and ignore all our expectations. Other than ego, I really don't see the point in doing that, but you're free to opt out.
No, what's ridiculous is how it worked before, people being allowed to reach user directly without any control. The security argument alone makes it unacceptable. The consistency is ridiculous too... you're talking about the size, if I take just the top 10 largest themes I get 100MB! If I take the 10 smallest I get 6MB.... you see what's ridiculous? People shove MDM themes, backgrounds, icons within their ZIP file, files which get burried in /usr/share/themes/theirspice/ and which people don't even know they installed. You can mention the cons of using one archive, and there are some, and they are valid, but don't call this ridiculous, it's far from ridiculous and it solves a huge amount of problems which themselves were utterly ridiculous. Expect this repository to continue to reduce in size by the way (it used to be more than 1GB when we got started). |
|
@Elbullazul icon themes aren't part of the scope and probably won't be. We talked about cursor themes within the team... which are much more easy to handle, and we got to the conclusion that it really wasn't our role to manage this. At least at the moment we don't want to support additional types.
The theme repo is too large and we're going to address that. We'll remove themes which are unpopular, we'll clean up files which shouldn't be there, etc etc. Keeping up to date is easy. Make sure to pull before working on changes, use a branch, keep your commits modular and simple so we can merge them fast. We'll be strict on expectations and we'll define them so that they can be followed and we can merge things fast and delegate PR reviews.
Ah, he must have forked it. I wish he used his own name for the theme... that's not cool. There's no question this name/uuid should be yours then. I'd recommend making a PR which deletes his version and adds yours instead. If he feels there are significant differences in his version he can always resubmit it, but under a different name/uuid. |
To be fair, you probably won't want icon themes on a repository either because of icon packs can be very massive in size, which would cause an increase on Spice Space Usage and/or GitHub space usage, and then there's the possibility that some of it will be "too big" for GitHub and GH will simply refuse to load it... |
|
@leigh123linux, @clefebvre @kevlogan90 I perfectly understand the necessity of a new model and the update. I also know this is difficult and not always the best for one thing it's the best for other things. I also known that always in all decision that we take will be other people affected for that. Maybe also we can not understand why they feel affected or why they take some decision base on our own decision that was taking for the good of users, how we feel it's more easy, or whatever. Developers are also users, but in some context they are not acting as a user. This is how the live it's and we need to live with that. There are a lot of people that like that his work will be taking more seriously, because they like to feel they are part of the project, because in first place the project it's a good project. There are others who feel threatened to belong to any organization, political or religious, or whatever. I think the decision it's good for cinnamon, but not for devs that have his own intentions with his work. I think how we need to take in consideration if we will feel good with one distro or with another or if we feel good with one desktop or with another. We also can feel good or bad with one decision or with another and we also can react to this like we want. So, understand this is affecting my personal intention and this is not more than that. I don't say this is wrong for cinnamon, or this is wrong for users... Not, this is not a thing like that, it's wrong for me only. Thanks for explanations. |
|
@kevlogan90 you don't need to install a three-party extensions, not one it's forcing you to do that, but if you can do that it's because the development of this extension was for you. Was not the Mint team, not the Cinnamon team how wrote the extension. Don't worried, will be a lot of more extension in spice sure. Just, will not be because of me, that's the only difference. If i also are feeling bad abut it i don't need to share my work. I can move my work to gnome shell or simple stop the development or remove my github repository. It's my decision, but it's just my decision, this not mean nothing more. |
|
Thanks lestcape, I agree with everything you said there and I thought you summarized the various positions very well. I understand the worry. Obviously I'm on the other side of the fence and I'm confident this is a great improvement overall, but I do understand all the same. My advice to you is this. Give this a chance and the benefit of the doubt. Don't opt out based on worries and fear of what's to come. Give it a few weeks so you can try the workflow, not only to see how we react to your changes, but also how other people interact with your work, and then you can make a decision as whether this suits you or not. You might find it excellent, you might find it unacceptable, in any case you'll be making your decision to stick to it or to opt out based on experience rather than predictions. |
|
Also, we've defined the intention here and the expectation. We want things to work, safely delivered and with consistency to users. When it comes to practice and using the new workflow, we'll see needs arise and we'll need to adapt I'm sure. We're already short on the definition of authorship (which is something we need but which isn't formalized yet) and the ability to embed instructions (for instance a README.md that would be embedded in the site so you can read it both on github and on the spices website). We'll get a lot of feedback from you as you are using this new workflow and things will improve as we address them. |
|
In regards to upcoming changes:
|
|
@clefebvre This is what I was kinda thinking of for the System Info screen in Settings (kinda): |
|
@clefebvre just for record, you do not increased the security, because an xlet can download dynamically a new code from a source and install it in the user domain. This code could be an utility, like occurs in configurable menu (#6130 (comment)) and you never see that, but also can be a malicious code. And like it's outside of the xlet, you can not review this and also if you review the outside code, we can change the code after a review. A system is as safe as its weakest point is so safe. So, security it's not the point here. |
|
Hello, everybody.
@clefebvre: This sentence made my day!!! I was already using my rendered README files as my spices descriptions. I was starting to think that you guys want us to annoy us on purpose by forcing us to use escaped HTML code inside a JSON object! LOL The size of the repositories was one of my worries too. Not just for their size, but also for the amount of folders that we would have to deal with. I worked around this annoyance by simply making use of the git API (sparse checkout mixed with shallow clone). It still has to download a lot of data, but one can work with only a limited amount of data checked out. |
|
Keep in mind we are looking to reduce the repo size as well. A lot of the spices include things they don't need or shouldn't really contain. Just give us a bit of time and hopefully this will be improved. |
|
@Odyseus the cinnamon installer that you fork will not work, it's in development, the last release version it's what configurable menu download. You can continues forking all and I have not problem with it, but i will not remove anything from my repositories, and certainly I'm on gnome shell now and i'm moving all things and also all cinnamon behaviors and the ui code and the applets and desklets code to gnome shell... But thats not mean i will remove my repositories. |
|
We're down to 120MB (we started at 1.5GB) for themes, and we're not finished reducing. It's going to continue to go down. |
|
Security is night and day compared to before. I'm sure you can write code which downloads remote code, and eventually we'll crack down on that as well*, but you can no longer register an account on spices and upload a ZIP file which "rm -rf ~" without anybody even knowing about it. *If you know of spices which download and install remote code, do let us know by the way, you'll save us some time. I don't think we want to allow that. |
|
Authorship was added to all spices into info.json at the root level. For many spices it was parsed automatically from the uuid, so it will need to be corrected as it isn't right in all places. Also, it's supposed to refer to the author's github name. We'll explain this in details in the README.md of the 4 github repositories. |
|
Mardown support was added. Place a README.md and include markdown content (same syntax as in Github) in the root directory of your spice (i.e. beside info.json, screenshot.png, files/) and it should show up on the website. Note:
|
|
No sign of the favicon just yet. And I'm going to have to postpone the most important aspect, the definitions... to Monday. |
|
@clefebvre you can write a tools for inspect extensions automatically. Probably one for python and another for javascript, to detect the usage of functions or libraries that could have security risk and make things more easy. But then, you will need to decide what you want to do with it, because this is clear a risk, but also it's a way to increase functionalities and there are a lot of applications with the ability of auto-update, and thats occurs without the usage of the system mechanism for update applications. There are also a lot of packages that only contains an updater, because probably they download an application that are not in the repositories (maybe because the author not want to share it or waverer) from the author web page. The true it's that a little revision will not help for security. There are a lot of way to cause damage, if you want. For example. You can write a method for clean the recycle in an applet, but this is a general method. Then in another extension load the applet an call the method with another directory parameters to do an "rm -rf ~" . Like you say, thanks for God, not one have this intention yet. |
|
@clefebvre On a related note, is there interest in more GJS upstream PRs in CJS? I see some in the repo for bug fixes, but none that are keeping pace with GJS' increase in features, such as Promises. |
|
Definitions included today. Each repo received a README.md. It's a first draft but hopefully it clears things up a bit. @jaszhix you can include the src in the root level if you want. As long as it's outside of files/ it won't be included in the ZIP. |
|
I forgot to mention, you can also put instructions and warnings/recommendations in the README.md (root level as well). For instance you could tell people how to PR your spice in there. |
|
I'm closing this since the original request is now implemented. Discussion directly related to it can happen in issues on the various spices repos. |
Hopefully this is the right place to put this, but one of the biggest pain points for me right now is the growing list of applets/desklets/extensions (mainly applets). I think a big problem is whoever made the original code stops updating, and then another user forks that to keep going since they don't have access to update the original.
If there was a single repo that all users can push updates to, that might prevent further forks. A simple example would be the force quit applet. If it was managed by the Mint team the user could've requested an update, and one of the owners could merge it.
Since currently no one on the Mint team reviews what users put as applets, it wouldn't require much time since no one needs to even review the code, they just need to merge.
There are a few downsides, but I think in the long run, this would be a good thing to do.
The text was updated successfully, but these errors were encountered: