Cinnamon: [Suggestion] Make repo for applets/desklets/extensions

Plesse take note of mtwebsters comment here https://github.com/linuxmint/Cinnamon/issues/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?
It would be an amazing time saver as you wouldn't need to zip and manually reupload every time you make a change.

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.

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.
I don't see how it's different then what we already have. You would just download the zip off github and parse the README.md file.
One could even incorporate the issue tracker.

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

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 :wink: :pray:

@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 :open_mouth:

I like the idea. Granted it isn't as automatic as my proposal (I'm a lazy ass :smile:), 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.
@zagortenay333 I can not give details, because the details depend of how this will be implemented and it's not in my hands decide this. Just be sure easy it's not, So, another reason to say thanks for the enforce.

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

Collection of open Issues regarding Cinnamon-Spices:

• https://github.com/linuxmint/Cinnamon/issues/5502 (Spices.py : Maybe Shell Injection with a filename)
• https://github.com/linuxmint/Cinnamon/issues/5356 (Auto updates for widgets (applet, desklet extensions))
• https://github.com/linuxmint/Cinnamon/issues/4978 (applet release procedure is too permissive)
• https://github.com/linuxmint/Cinnamon/issues/4334 (Depends and conflicts should be supported for spices)
• https://github.com/Koutch/Cinnamon-systray-collapsible/issues/5 (Ordinary system-tray should be removed from panel when collapsible is being added)
• https://github.com/linuxmint/Cinnamon/issues/4149 (Broken/unstable cinnamon applets/extensions should be removed, fixed, or have a visible warnings.)
• https://github.com/linuxmint/Cinnamon/issues/3937 (Using panel applet icons after installation)
• https://github.com/linuxmint/Cinnamon/issues/3809 (show extended description of extension inside cinnamon settings)
• https://github.com/linuxmint/Cinnamon/issues/3356 (Allow themes to be customized)
• https://github.com/linuxmint/Cinnamon/issues/2813 (Category for Applets / Desklets)
• https://github.com/linuxmint/Cinnamon/issues/2811 (Ability to rate Applet / Desklet / Themes in Cinnamon settings)
• https://github.com/linuxmint/Cinnamon/issues/2441 (Spices (App/Desk let) - Update Warning - Active items)
• https://github.com/linuxmint/Cinnamon/issues/2280 (Local automatic installation.)
• https://github.com/linuxmint/Cinnamon/issues/2215 (Tell the user to refresh the applet cache)

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.
I like the GitHub idea but not this review-to-always-working thing. I wonder what would happen if you decide to take a way in the development of an xlet and two months later the owner takes a different one. Would they have to fork their own work?

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

@lestcape @germanfr

The current state of spices is crap, at least 50% of the stuff there is broken!
If it doesn't change I will probably remove spices altogether from fedora cinnamon.
As for offending a few devs who cares?, I rate security before ego!

@lestcape

Fedora is sponsored by redhat and receives all it's infrastructure (web and hardware) from them.
Ubuntu has some millionaire 'dick head' sponsor this hasn't stopped you using it.
In fact most distros have there web space/bandwidth donated.

I'm not working for organizations that recive donations.

@lestcape @germanfr

It's not like xlets are here for no reason, they're here to enhance cinnamon. If the owner of an xlet stops development, or the xlet becomes incompatible, then cinnamon suffers. This is the main reason why I think there should be a version they own (and maintain it when necessary).

@clefebvre here are my thoughts on how this could be handled. (Take it how you will.)

1) Any new xlets could be requested to be added to cinnamon repo with a link to the owners repo. (Try to encourage stable/dev branches so there is a good balance between stability and new features.)
2) Cinnamon should fork the original owners repo and have it regularly updated to the HEAD of the original developers stable branch. (This means no code reviews are necessary from the owner.)
3) The fork should be the original owners applet first, and only when they aren't upholding compatibility/security for whatever reason, then should the cinnamon devs step in to make sure it stays compatible. (Up until that point it should basically be a centralized clone though.)
4) The original developer still owns their applet (and can make all the changes they please), and cinnamon has a version it can maintain (when necessary).
5) The original developer would still be recognized seeing as the repo would be forked directly from their personal repo. (Also see point #6.)
5) If the original developer stops updating and someone else wants to take over, or it needs to be updated by cinnamon devs for compatibility, then those updates would be happening directly on the forked version. (Although ideally I think it would be nice to attempt to go through the owners repo first. Not sure if cinnamon devs would want to make a PR on the owners repo for compatibility updates though. See point #3.)
6) There should be a few available "versions" of the applet (i.e. the "cinnamon" version (from cinnamon fork), the "original" version (from owners stable branch), and possibly a dev version (from owners dev branch). Also, the "cinnamon" version should be identical to the "original" version (unless cinnamon devs need to update for compatibility)
7) The cinnamon devs could bundle up their fork of the xlet into releases, so users could download previous versions if they wanted to, and have a file with compatible versions of cinnamon for that release, so users can be alerted to possible incompatibilities.

I think these points would be able to handle most (if not all of the points @lestcape brought up in the first comment and most recent comment).

Hi,

This is going live today.

I'll make an announcement on segfault with explanations on how it works.

Here's a couple of answers in the meantime.

I hope this will be available soon.

Today.

I want to remove my xlets from spices, but i can't do that right now because it's in migration.

You can. To remove a spice, you PR the github repository and delete the spice. 5 minutes later it's gone from the website and no longer available in people's Cinnamon DE. This will be explained today.

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.

Ok, I understand this. Note that you already PR projects such as Cinnamon though. The only difference here is that your name is on the spice. If that's an issue for you we can take on the role of author from you so the spice is no longer advertised as being yours. You would lose moral ownership over it though. I don't suggest you do that. I think your issue is slightly miscommunicated here and you're worried about empowerment. We'll explain this today, but when it comes to empowerment, the author is still the moral authority.

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 actually think it makes it more visible that the work comes from you. Anyone is now able to see the spice's history on github along with all its commits.

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.

There are two teams on github (one for artists and one for devs) which have direct write access to the master branches. These teams are distinct from the Mint and Cinnamon teams, they were created to include more artists and more developers, not only so that they can continue to work on their own spice without needing to go through a PR, but also so that they could help maintain the entire spice ecosystem. If I take your example lestcape, you've been developing for a while, you're a known figure here and you are trusted. You don't need to PR, you can just commit with access to this team. You'll understand that we can't blindly trust newcomers though. One of the key problems with the way things worked before is that anybody could write some malicious javascript, upload it to the spices website and have people downloading it blindly from their System Settings and running it from within Cinnamon... that's crazy and it had to stop. With github we can ensure no malicious code goes in, we can see if/when it ever does and we can revert it.

I don't like the idea of someone reviewing all I do.

There's no choice on that. We can't afford to let people download stuff nobody reviewed. Imagine if somebody uploaded malicious code as a spice.

It would make me feel bad each time I upload something because I will know someone will have to work on it.

Up to a certain point, because once you're familiar with the process and trusted to respect it, the ecosystem and obviously not write malicious code, your work no longer needs to be reviewed and you no longer need to use PRs since you can commit directly to the master branch.

And I'm of those who NEVER uploads just once because I always forget something.

Oh wait, you can't do that, you could NEVER do that in fact. In the past when you uploaded something half-cooked, it was immediately available to users.... and it's the same going forward, whatever gets into the master branch ends up being available to users 5 minutes later. If you're afraid or forgetting something do it on a fork, or create a PR with a WIP prefix so it doesn't get merged just yet.

I like the GitHub idea but not this review-to-always-working thing. I wonder what would happen if you decide to take a way in the development of an xlet and two months later the owner takes a different one. Would they have to fork their own work?

I'm glad you're asking this question. Each spice has an "author". That person is the moral owner of the spice and decides the direction taken for its development. If that person PRs that spice, the only thing we look at is the absence of malicious code. We don't test the PR, we don't review the code styling, we don't even review the idea behind the PR, because it's not "our" spice, but the spice of that person. We don't want malicious code and so that's our main concern when reviewing people's work on their spices. Now... if somebody else PRs that spice, we'll require the author to approve it for us to merge it. And finally, the question of us working on the spice directly. If we want to change the way the spice works, we can PR it and require the author approval. If we want to fix something that is broken we might do it directly. We can also intervene when the author is gone and no longer involved, but in this case, before we actually act on his behalf, we'll want to change the author info (effectively that would be similar to forking the spice and removing the old one).

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.

It's the same issue as with the old system. How can you trust "anybody" and expose code that hasn't been reviewed to be interpreted by people's DE? It's a huge security risk. People can download from 3rd party websites already, and that's ok, because when they do it's up to them to assess the risk, but when they install things from within the System Settings or the official spice website, we have to guarantee the absence of malicious code.

There's another reason other than security to have spices in one repository too, and it's to do with maintenance. It allows us to implement across-the-board fixes and inject support for upcoming versions of cinnamon all in one go. For instance with 3.2 a lot of themes stopped working, that's something we could have fixed (and I'm hoping we'll do it soon).

Wait a minute. How am I supposed to have my own repo for my own spice in this model? I need to maintain a copy of mint's themes repository and work inside of it, or work with basically two repos, my own and the shared repo, while copying from one to the other.

Hi @clefebvre thanks for answering. I've read the segfault's note.

If it has to be in a git repo why can't it be downloaded directly from the owner's?

It's the same issue as with the old system. How can you trust "anybody" and expose code that hasn't been reviewed to be interpreted by people's DE? It's a huge security risk.

I agree with the security problems, but you could already review it from your servers. I do this for fun and I really like to upload my things to the spices, but these are only troubles. It is already done, and I know there have been a lot of work behind, so I'm not going to ask for a change. But there's always place for improvement so here are some problems I find with it.
I have to maintain a fork of your whole "server" in my computer. Not a big problem now, but there are lots of themes already and it can grow even more. Another problem I see with this is that I cannot create a PR from my repos to yours because they are totally different. I'll have to replicate my commits into your repo's fork or squash them into a new one, loosing the collaborative thing because of long unreadable commits. ~That could concurrently be achieved with an upload button that automatically created a PR in your repo (so that you can review changes) without the need of forking and it would be easier for us :)~ (Already implemented on github).

Good job, looks superb

PS: Will Cinnamon Settings > Info ever get the Cinnamon Icon along with the distro's own logo? Been thinking of a few ideas for it

I agree with the security problems, but you could already review it from your servers.

The simpler the review process is the faster we can approve changes. If we need to review ZIP files without version control this would take forever... I'm pretty sure you'd be waiting a long time before your ZIP file goes through, if it ever did :)

We're used to working with git, it's part of what we do already, it's integrated in our workflow and let's face it it's one of the coolest way to work together and to review changes. There's no question here we prefer to use github than our own review mechanism.

I have to maintain a fork of your whole "server" in my computer. Not a big problem now, but there are lots of themes already and it can grow even more.

Yes, that's an issue and we talked a lot about that within the team. It's not an issue for applets, desklets, extensions but it can be an issue for themes depending on people's resources and bandwidth. That said, the theme pool shouldn't be that big either. With 200+ themes, it also means we're not selective enough and not proactive when it comes to deleting themes people don't like. You'll also see themes which are larger than 1MB, some being even larger than 5MB or 10MB and that's not acceptable. So there's a lot of work there to reduce the size of that collection and that's something we need to tackle.

It's also worth mentioning that centralizing spices together isn't just a cons but also a pro. @zagortenay333 mentioned the fact that he'd rather work on his directory alone.. and fair play to him, that's an understandable observation, but having the other spices in the pool beside it also means he can query the git changes globally, search for resources similar to his and apply bug fixes globally to multiple spices, which is something we want to encourage.

Another problem I see with this is that I cannot create a PR from my repos to yours because they are totally different. I'll have to replicate my commits into your repo's fork or squash them into a new one, loosing the collaborative thing because of long unreadable commits.

Yes, and that's because you're no longer upstream from a development point of view. You can copy changes over but as you said it's clunky and it's not designed to accommodate this. I would suggest you clone the entire repository and work on it directly. Long term you won't just keep track of changes specific to your spices anyway, you'll also want to keep track of global bug fixes affecting your spices and others.

@feren ah, I don't know... the design team is working on the favicon on sunday, that's all I know so far in regards to the new icon.

because of long unreadable commits.

I forgot to mention... I thought you knew already, but you can keep track of git changes for a specific directory. If you git log your applet within the repository you only see the commits relevant to it. That's what is shown to visitors too when they look at your spice on github.

Last but not least, I talked about this on blog.linuxmint.com and on segfault but I'll also define a lot of things on github going forward and we've got more support coming up.. for instance we want to let you add a README.md at the root level of your spice and embed that into the spice HTML page on the website.

That way you can continue to post instructions and details, without shoving things into the description field of the metadata.json file.

Yeah, I don't like this at all. Not for me. :disappointed:

• I don't want to work on other people's themes (fixing their bugs, updating to new cinna releases, etc..), and I'm pretty sure most people don't want to either. Trying to encourage this is pretty futile.
• I don't want my work to be amalgamated with others in this way, and no amount of crediting can correct this.
• The workflow this introduces is ridiculous. I have to deal with a cyclopean repository and work within it or somehow copy into it..

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

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

1. Big size of repo, and possible trouble keeping up to date
2. Hassle of working with two repos for my theme(s?)
3. Cinnamon spices just crashed my browser loading all thumbnails, files & stuff; maybe notebook navigation will be better?

Also, just a small note, the Chrome OS theme you credit to brahimsalem is actually mine: https://github.com/elbullazul/chrome-os

@zagortenay333

I don't want to work on other people's themes

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.

I don't want my work to be amalgamated with others in this way.

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.

The workflow this introduces is ridiculous. I have to deal with a cyclopean repository and work within it or somehow copy into it..

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.

Big size of repo, and possible trouble keeping up to date

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.

Also, just a small note, the Chrome OS theme you credit to brahimsalem is actually mine: http://b00merang.weebly.com/chrome-os.html

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.

@Elbullazul @clefebvre

On the subject of icon themes:

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:

• We should get formal definitions and descriptions of processes and structure on github this weekend (we'll define where things go, how to format PRs, people's roles, guidelines, technical details on how uuids, versions and timestamp generation work etc..).
• We should be getting a favicon using the new logo on Sunday or early next week.
• All spices should be given proper authorship this weekend (there's a little debate within the Dev. Team as to where this metainfo should be stored, that's why it's not there yet and that's why spices show as being "by Unknown" right now).
• We might get README.md support during the weekend. I certainly hope we will, I'm not 100% sure if it will happen during that time just yet. In any case we'll include that in the definition so even if the website doesn't show them, at least you'll know where to put it and how to use it.

@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 (https://github.com/linuxmint/Cinnamon/issues/6130#issuecomment-269731755) 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.

for instance we want to let you add a README.md at the root level of your spice and embed that into the spice HTML page on the website.

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

• Please don't include changelogs in there, versioning and changes are handled by git and the workflow already.
• Please clean up the description field in info.json (for themes) and files/*/metadata.json (for other spices). This should only be a very short description, a single sentence really, with no HTML tags.

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
My applet is transpiled from ES2015 with Babel, so the real source is not distributed with the applet. Would I be able to include a src directory in the root of the applet directory, next to files? That way if someone does end up modifying the code, they will at least be looking at the same version I am. And of course whoever does this would need to run the gulp task and transpile it - its an extra step, but it makes development smoother for me as I have been using ES2015 since it was standardized.

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.