Cinnamon 2.0 released [LWN.net]

Cinnamon 2.0 released

Posted Oct 14, 2013 8:07 UTC (Mon) by ovitters (guest, #27950)
In reply to: Cinnamon 2.0 released by torquay
Parent article: Cinnamon 2.0 released

An unstable API is not a given that it cannot be relied upon for Cinnamon. If the needs are shared with GNOME, we can look into things. What was done instead is a fork of gnome-shell. Due to Wayland, things are being shuffled around between the various GNOME components (usually to gnome-shell). Externally, we still provide the same APIs (e.g. the screenshot bit moved, but the d-bus API is the same).

As Cinnamon forked gnome-shell and things are being shuffled, you basically need to incorporate the same changes. Which GNOME handles for you if you use the extensions infrastructure.

Not speaking against forking. People are totally fine to do that. But then don't forget that we do have an API. The API is not perfect, but that's because things change when needed, like Wayland. Eventually those changes will quiet down. At the moment Cinnamon seems to solve everything by forking. But then you don't get the bugfixes as well and from what I've read, they don't merge bugfixes from GNOME into their fork.

To me:
1. Don't fork, rely on extensions API, make needs known. Some maintenance work needed, but you do get new technology for free (Wayland) as well as bugfixes.
2. Fork. Fork more components as things change. Maintenance includes keeping up with bugfixes made upstream.
3. Anything else. Could even just branch gnome-shell. E.g. mutter-wayland is just a branch in the mutter repository.

to post comments

Cinnamon 2.0 released

Posted Oct 14, 2013 9:28 UTC (Mon) by torquay (guest, #92428) [Link] (4 responses)

The API is not perfect, but that's because things change when needed, like Wayland. Eventually those changes will quiet down.

The problem is that Gnome doesn't have the greatest reputation here. "Eventually" is rather ambiguous. Is it 6 months from now, 1 year or 2 years? People don't have that much patience. Instead, they want to ship something usable today, without continually adjusting to other parties that have their APIs in continuous flux. It's too tiring, and frankly, frustrating.

This brings another question. When Gnome 3 was released, Gnome 2 was declared abandonware, even though it was stable and proven technology. If and when the Gnome 4 experimentation starts, will the "finally finished" Gnome 3 also suffer the same fate as Gnome 2, or is it going to be declared as supported, stable, and parallel installable with the "work in progress" Gnome 4 ?

Cinnamon 2.0 released

Posted Oct 14, 2013 10:03 UTC (Mon) by ovitters (guest, #27950) [Link] (3 responses)

A lot what you're asking is already addressed in my reply.

I'll try again and say what I said before:
1. Currently Cinnamon forked things and doesn't do much maintenance on their fork. E.g. bugfixes made in gnome-shell are not merged in Cinnamon.
2. If you do fork, then there is an increased maintenance burden (merge of bugfixes, merge of changes in infrastructure).
3. If you fork, then there will be a bit of maintenance you have to do. It is not going to be free.

Your question regarding GNOME 2: For GNOME 3, a lot of components were ported to GTK+3, then a small change was made in configure.ac, the result was declared "GNOME 3". This is highly similar to any GNOME release. No matter if that's a 2.x release, or a 3.x release.

If you want GNOME 2.x, then this is maintained by MATE. We (also me personally) have ensured that they can use GNOME infrastructure. Note that a lot of things they do, is actually just merging the things that were already done just before putting a "3" and a "0" in various configure.ac files. It just that they forked too early.

Since a few GNOME releases, maintainers do maintain the stable version of GNOME for a little bit longer. E.g. GNOME 3.10.0 is out, but there are still individual releases going out for 3.8.x. That is pretty unique historically.

If we decide Wayland is awesomely cool, maybe we'll change the version number from 3.12 to 4.0 to indicate a major feature change. Practically, a major release allows us to get rid of deprecated functionality, nothing more. For version numbering, a major release is usually done to indicate major feature change.

In any case, there is not a huge change between GNOME versions. And 2.32 -> 3.0 was not a huge change for the majority of the components. So to answer your question: Look at the MATE maintenance and how much is (or could be done) by merging code.

Note that Abandonware term implies that we don't care about copyright of GNOME 2, which is not true.

Cinnamon 2.0 released

Posted Oct 14, 2013 13:27 UTC (Mon) by torquay (guest, #92428) [Link] (2 responses)

1. Currently Cinnamon forked things and doesn't do much maintenance on their fork. E.g. bugfixes made in gnome-shell are not merged in Cinnamon. 2. If you do fork, then there is an increased maintenance burden (merge of bugfixes, merge of changes in infrastructure). 3. If you fork, then there will be a bit of maintenance you have to do. It is not going to be free.

I agree that forking has downsides such as increased maintenance effort, which can be considered as a form of cost. It shouldn't be done without weighing up the pros and cons.

The point I was trying to make is that perhaps the overall cost of forking (resulting in control over the API) in this case is actually lower than the cost of working with a continuously shifting/unstable upstream API. The cost of coordination with other organisations / developers should not be assumed to be trivial, especially when development directions are not well aligned.

On top of that, the current reputation of Gnome developers (whether deserved or not) is that they're not exactly open to outside ideas. This dissuades people from submitting upstream. It would take time and effort to dispel this.

Cinnamon 2.0 released

Posted Oct 14, 2013 17:01 UTC (Mon) by Rehdon (guest, #45440) [Link] (1 responses)

Also I think you're spot on with your remark about Gnome 2 being abandoned when 3 came out, it surely is a powerful caveat (although, to be fair, moving to a new paradigm makes sense ... throwing the baby with the dirty water less so :).

Rehdon

Cinnamon 2.0 released

Posted Oct 14, 2013 18:13 UTC (Mon) by ovitters (guest, #27950) [Link]

Didn't you read my reply? GNOME never supported anything longer than 6 months. Aside from this, a lot of work MATE is doing could (is?) have been done by taking the code developed after they forked it (they forked too early and too much).

Now for some interesting tidbit:
There is a conflict in the way MATE forked gnome-keyring into mate-keyring which makes d-bus start mate-keyring while the program was expecting gnome-keyring.

This bug was reported last week in Mageia. Bugs of course happen, but there are persons who often suggest that we went out of our way to not allow both to be used at the same time. However, we never supported that. And for the most part, we continued maintenance in the new release. It had gnome-shell instead of gnome-panel. The biggest technical changes were done partly in 2.x releases (moving to gsettings) and 3.8 (killing fallback mode). In 3.0 the major new thing was gtk+3.x. However, the preparation work was also done during 2.x.

Cinnamon 2.0 released

Posted Oct 17, 2013 16:22 UTC (Thu) by jond (subscriber, #37669) [Link] (1 responses)

It would be great if the Extensions API could be better documented, fwiw. Last I looked I found it astonishingly difficult to figure out what you could do or how you should approach doing it. When reading the shell source is your best option, there's a documentation problem.

Cinnamon 2.0 released

Posted Oct 17, 2013 19:01 UTC (Thu) by ovitters (guest, #27950) [Link]

I totally agree. At the moment you can do *anything*. Which means that anything can break between releases. It would be nice to just offer a minimal set with a stable API, then if you divert from that, you can, but can break. This probably means someone going through the existing extensions and determine what things are needed. This would at least make things clear for extension developers.

It would be nice if we had a team focussing on the developer experience. Documentating APIs, ensuring it is nice to work with, etc. Seems that the developers always have other things to focus upon (new applications, Wayland, getting rid of fallback mode, etc). IMO such detail belongs to a different type of team. Meaning: spend 90% of time to make a nice interface, another 90% getting the details right ;)