This post is for developers of Cinnamon applets, desklets and extensions, and for artists who design Cinnamon themes.
Please make sure to read this post first, to see changes explained to users: http://blog.linuxmint.com/?p=3199
We’re introducing changes in the way Cinnamon spices are being developed and maintained. All of them are beneficial to Cinnamon users and that’s the most important aspect. Some of them are also beneficial to you as developers and artists and I hope you’ll enjoy them, and some aspects might also be annoying as we’re raising expectations, defining standards and limiting your empowerment going forward. In this post I hope to explain what’s being changed and why we implemented these changes. I hope you’ll enjoy them, if not all aspects at least some of them and I’ll be happy to answer questions you might have.
In the past you were fully empowered and we didn’t get involved at all.
You could write anything you wanted and include any kinds of files in your ZIP archive, upload it to the Cinnamon Spices website and have users download and run what you uploaded.
It was great for some of you because there were no delays, and no intermediary between you and your users. People could comment on your spice, you would make changes and as you clicked the upload button, your new version was available to them.
The problem with that was that you were on your own…
- If for some reason you weren’t here, no change happened (some developers haven’t been “here” for about 4 years now..). Nobody else but you could fix bugs so the only way to fix something without you was to fork your spice.
- If for some reason you weren’t reviewing every single spice every so often to see all the changes that other developers are implementing you might have missed changes that could benefit your spice… and nobody can do that, but because you’re all developing your own spice in your own corner of the Internet, a bug fix or an improvement only affects one spice and rarely gets ported to other spices.
- If for some reason you didn’t know how to do things, you didn’t do them properly. And it’s not really your fault. We can’t expect you to know about all the new features we implement in our API, the proper way to do something, how to support multiple instances, multiple panels, etc etc… we can’t expect everybody to keep up with the information we post (which itself isn’t sufficient to understand the core of these APIs the way we do) and so what we see a lot are spices developers which find inspiration in /usr/share/cinnamon/js files or by copying what’s being done elsewhere in other spices. And that’s great, and it works, but it’s not ideal. Ideally we’d want to be there beside you and help you change things when we see something that can be improved.
- If for some reason you wanted to inject malicious code in a spice and upload it to hurt people, you could. And nobody did, thank God. But it’s not good enough going forward, nobody should be able to. Not only you could, but when we find out, we wouldn’t know when you did and what the exact changes were, and that’s really scary. Depending on who “you” are, maybe we can trust you, and we’ve got a way to do that, but we certainly cannot trust everyone out there. Anybody could sign up a new account and upload malicious spices, and that couldn’t go on.
So you probably guessed it by now, we’re taking over and restricting things. That means less empowerment for developers or artists on their own spices, but it’s also a good thing because we’ll be able to assist them when it comes to packaging, bug fixes or even support for new versions of Cinnamon.
We’re placing ourselves as a delivery intermediary between the authors of spices and the Cinnamon users.
Our role will be to:
- Review all changes to guarantee the absence of malicious code
- Implement changes to guarantee proper packaging/installation of spices (files being in the right place for instance)
- Implement bug fixes and accept bug fixes from other people than the author
The development of all the spices now happens on Github with the following repositories:
Changes are done via pull requests against these repositories.
Changes merged onto the master branch are automatically synced towards the https://cinnamon-spices.linuxmint.com website.
The workflow is as follows:
- You create a pull request implementing a change in your spice
- Your pull request is merged onto the master branch
- The Cinnamon Spices pulls the master branch, detects your commit, regenerates its copy of the spice, its ZIP archive and the global JSON index used by Cinnamon.
- When people look for updates in System Settings, they see a new version of your spice
Each spice comes from an author and that is something that is fundamental to us. We might be taking over and restricting your empowerment, defining standards and expecting you to follow them, it doesn’t change the fact that you’re still the author of your spice and that you have moral authority on how your spice is developed.
Nobody is going to force you to make changes in the way that spice works, and nobody will be allowed to change its behavior without your approval.
I don’t want to get too technical here just yet, I’d rather do it on Github when we formalize standards and process in .md files, but the general idea here is that you decide what your spice does and how it does it:
- Each spice belongs to an author (which used to be in the uuid, but again I don’t want get technical here, it will be placed in a new file… the important thing is that there’s a one to one relationship between a spice and its author).
- A pull request made by an author on his spice is ONLY reviewed for security and deployment reasons. In other words, if you pull request your own spice, the only thing that we look at is whether you’re injecting malicious code or not and whether you’re putting files in the right place.
- A pull request made by somebody else on your spice ONLY gets accepted if it limits itself to bug fixing.
- A pull request which modifies features or visual aspects of your spice WILL NOT be accepted without your approval.
Two teams were created along with the 4 github repositories, one for artists and one for developers.
As you work on spices, and even more now with us being part of their maintenance, ties and trust will develop between you and us. There are no formal distinctions or requirements when it comes to the Linux Mint team, or the Cinnamon team, we’re all developers and involved at different levels and in different projects. It’s hard to really define what the core team is and who’s part or not part of it, but the more we work together the closer you get to other developers and start being part of whatever “this” is.
At some stage, when you’re familiar with the processes, expectations and trusted by your peers, not only is there no need to review your changes anymore but you also have the ability to help us review other people changes and accept their pull requests. From a technical point of view, there comes a point where some people will be invited into these teams, so that they can get access to the master branch, commit directly and help review other people’s pull requests.
Conventions and standards
We’ll define conventions and standards as we go forward and these will be written in README.md on the github repositories. In particular we’ll define the role of uuids, authorship, team membership and standards related to pull requests.
I hope you’ll enjoy these changes. Some of them might be hard to swallow if you read this a little too fast. You’re losing empowerment and somehow technical ownership basically and I can understand if you’re worried about this. You’re also getting us in the equation though, we’ll make spices work and install smoothly, we’ll add support for upcoming Cinnamon changes as we go forward and we’ll bring bug fixes to your spice without stepping onto its design, its features and what belongs to you.
Some of you might not be familiar with Github, artists especially and I hope this won’t be too much of a learning curve. Git is a lot of fun to use and to learn, don’t hesitate to ask questions if you’re new to this.
And then many of you are also missing and some of your spices weren’t ported over. Spices started 4 years ago, some haven’t worked in years, some were getting negative scores… We can’t guarantee that we’ll welcome all spices or that we’ll keep all spices, we want them to be popular and we want them to work. Eventually they’ll all be formatted properly, smoothly installable and they’ll get bug fixes at a much faster pace than they got in the past.
Authorship is still a key concept though, and so in the absence of consensus with an author on a particular feature, we still recommend forking and the creation of a new spice. These are still “your” spices, you just won’t be on your own maintaining them anymore.