Cinnamon needs some love #1828

Closed
ubermann opened this Issue Mar 30, 2013 · 23 comments

Projects

None yet
@ubermann

I hate to meddle in other people's business, but I am really concerned about Cinnamon future and about its leadership.

Cinnamon development looks sadly neglected, and sometimes I even wonder if it will be abandoned. It's been weeks with no significant activity in the master branch. Cinnamon spices website appears desolate as well, without any recent update. It's also been weeks, or months, without any desklet or extension uploaded.
There is a huge pile of open pull requests that are accumulated for an unacceptable amount of time on github, some of them, astonishingly, are 5 months old, or even older. They were not merged, reviewed, closed and not even commented by the staff of Linux Mint. That indifference is an unfortunate disrespect to the voluntary developers.
I assume that Clem is a very busy person and clearly he doesn't have enough time to dedicate himself to the project. Obviously he has personal and professional duties and commercial obligations that prevent him from giving Cinnamon the proper attention. Mint is growing more and more, and Cinnamon is only a part of Linux Mint. The other project leader, glebihan, apparently doesn't have time to Cinnamon either. Even if he had time, he seems to be allowed to merge on his own account only minor low-profile pull requests. What I'm saying is nothing new, the problem has existed for some time now. Maybe the Mint staff had no idea how difficult it would be to maintain by themselves a forked DE.

I've noticed that voluntary developers have been having a hard time rebasing constantly their stagnant pull requests, multiple times. Months go by until their pull requests are addressed and (perhaps) merged. I'm sure they are willing to implement several other new features, but they would have to wait to the huge stack of pull requests get merged. I suspect they could easily provide fixes to Cinnamon's numerous trivial bugs, but they probably don't have motivation to do so, and countless issues remain ignored. The worst thing is that innovation is held back because developers are not going to waste their time with something that can take months to be reviewed. Actually, I think this is one of the main reasons why Cinnamon has such a small team.

Moreover, users requests and bug reports are continuously ignored. Take this issue, for instance: #130 . There are more than 70 requests to implement taskbar on multiple monitors. A guy even offered money to whoever creates that feature. Two developers had started working on it, but they had to give up because there was not a single feedback from the project leaders about the issue.

From Clem's point of view everything must appear convenient. Most of the work is done by voluntary contributors, and he only has to show up just before merging their commits. I've noticed that now and then he takes a few hours to merge many pull requests at once, and Cinnamon suddenly gets a boost in its development, with many new features being included in a very short time. But from the perspective of developers this situation must be extremely frustrating, because there is intolerable inactivity throughout most of the time. I am afraid that some developers could reduce their contributions to the project for that reason. Cinnamon is still far from being feature complete or stable; it needs new functionalities and a faster and steady pace of development to compete on equal terms with other DEs.

Therefore, I have a suggestion:

Give merge rights to another developer with free time to dedicate to Cinnamon.

Edit 1: I'm aware that some people will suspect I'm some kind of disgruntled Cinnamon developer in disguise, which I am not, really. I'm just a user that has been following closely this project since its birth, but only now I've created a github account just to express my concerns.
Edit 2: Just to be clear, I actually love Cinnamon and consider it one of the best Desktop Environments ever created.

@blasphemy

Well, this is thoughtful and all, but I think the developers have a very clear idea of what they want to get in each release of Cinnamon/Mint, so that's why some things seem to get ignored for a while. If you want, you could make your own branch and try merging some of these "stagnant" pull requests. I've thought about doing it, but I'm far too lazy.

@gauravjuvekar

Extensions and applets are created by other users. It's not the devteams fault if people don't create them.

As for no blogposts on the website, I think the devteam plans to release Cinnamon 1.8(Which will be awesome) along with LM15

I agree with the fact that the current method of letting the pullrequests accumulate to about 50 and then merging 30 of them at once is a bit counterproductive.

Edit:Just see the commit activity graph. You can see a pattern there.

@ubermann

Indeed extensions and applets are created by ordinary users, but those users need some kind of incentive to continue working. It is symptomatic that the number of new uploads has dramatically decreased so much lately. Anyway, I was referring to the abandonment of the website as a whole.

The commit activity graph can be misleading. It uses mostly the dates when the pull requests were originally created, not when they actually got merged into the master branch. Even so, there are huge gaps in some periods.

Guys, I didn't mean to attack those in charge of Cinnamon, I just wanted to make constructive criticism. I really think it could help the project.

@bimsebasse

I think the gaps generally coincide with periods where Clem and/or Glebihan have to focus on Mint projects (e.g. preparing LMDE) - bottlenecking is inevitable. It's a bit sad to see some pull requests never making it or being taken down because of this (autarkper's alt tab improvements come to mind), and to think how much further Cinnamon could have advanced with speedier development, but it's probably safe to assume it's not because of laziness or neglect.

@glebihan
Linux Mint member

For now, I'd just like to correct a few things :

  • I am allowed to merge any pull request, but that doesn't mean I'll do it on my own without consulting anyone first : there have been a few remarks about the lack of discussion regarding new features, deciding on my own which pull requests get merged wouldn't really go in the right direction in my opinion
  • No bug report or feature request is ever ignored : it can take time to review suggestions, think of solutions and finally implement them. The taskbar on multiple monitors is a perfect example of this : there are lots of different ways to implement such a feature, each of them with pros and cons (and for the record, there was feedback on the first implementations)
  • The fact that there are phases of inactivity on the master branch isn't a problem and is actually normal : the development doesn't happen on the master branch and each series of merges is followed by a less active phase
  • Pull requests are never rejected because there is no time to handle them. It can take time, but if they fit the project, they will get in (autarpker's alt-tab changes were tested, both by me and clem, before the pull request was closed)

With that said, I do understand the frustration of developers who have to wait sometimes for months before seeing their pull requests merged.
And I really think that's where the problem is, and not at the user level : Cinnamon's overall development pace isn't slow and lots of new features are getting in (I'll let you compare 1.6 to 1.8).

As for your suggestion : I do think it would be good to have 1 or 2 additional developers with merge rights, but more than that, we need to improve communication and have a clearer roadmap, in order for all the developers to have a more precise idea of where we're heading at, and what changes are going to make it into a given version of Cinnamon.

@ubermann

About being normal the phases of inactivity on the master branch: I would agree with that provided we had another branch to test the newest experimental commits; the development could be faster there. But we don't have it (unless you are considering the nightly PPA as a satisfactory staging phase). The pull requests are merged directly into the master (stable?) branch. That is adventurous and risky (and somewhat amateurish). In fact, Cinnamon has a too short period of testing before being released as stable.

In all fairness, it's understandable that Clem wants to personally oversee every pull request. He has an admirable understanding of the user's needs and obviously he has also a sound aesthetic sense (with a few exceptions). And he actually listens to the users, a rare virtue within the current Linux world. I am not surprised he has created so many successful “products”. But I think he could delegate some of these functions without fear of ruining Cinnamon. That's why a testing/staging branch is important.

Cinnamon is fortunate in having such talented and dedicated contributors. This is not a rhetorical statement, I'm really impressed by the high quality of the pull requests. But we should not take these developers for granted. The project should get the most out of them while they still have the motivation to contribute, which will not be forever. Here is where the role of an efficient management is essential, to take maximum advantage of the freely available developers' time. Unfortunately I have a feeling that potential contributions are being unwittingly wasted.

@Rehdon

glebihan, thanks for your comments: unfortunately I agree with ubermann, once you discount the "inactivity phases" there's still much that can be done to improve the situation:

  • add at least 2 developers to the team with merge privileges, as you were suggesting yourself;
  • nominate one person as responsible for documentation and start building one place to go where you can get started with Cinnamon development: browsing the forums and the Cinnamon site I have the impression people would really like to do more stuff for Cinnamon, but documentation is really holding them back (see also all the references to "you have to understand how it works by studying other people work" in the applet comments f.i.);
  • nominate one person as responsible for the Cinnamon web page and delegate all the news and PR work to her/him: not only the last news item on http://cinnamon.linuxmint.com/ dates back to November 14th, but it still lacks a basic description of what Cinnamon is!

Disclaimer: I'm just a user of (and contributor to) Linux Mint who was wondering why the black outs in communication.

@dalcde

Documentation: #1629

@Rehdon

Hello dalcde, can I assume that you're talking about a documentation package, sort of cinnamon-doc? I was instead referring to the web documentation, or lack thereof, see f.i. #1835.

@dalcde

@Rehdon The patch will provide scripts to create web documentation that will be put on a cinnamon server.

@lockjs

I think Rehdon's suggestions are fairly on the mark, I feel the project just needs that little bit more structure. I would also add:

  • Alongside Dalcde's auto-gen documentation I'd like to see more along the lines of the Settings API pages on the Wiki or Code Ignitor's documentation, that makes it easier for newer developers to know how to use the API's
  • Tidying up of the "issues", applying tag's to issues, closing abandoned issues etc.
@clefebvre
Linux Mint member

Thanks for the feedback on this.

As you said, this worry isn't new and it's been raised by autarkper in the past. The situation is frustrating for contributors and developers because their contribution doesn't always make it in, and it can take a lot of time for them to be considered.

There's a few things which are important here though:

  • Cinnamon was not created as an independent project. It was created for the very specific reason to implement the DE Linux Mint needed. As such, Cinnamon does not compete to be the number 1 DE and it's pace isn't measured against what it "could" be if all our resources went into it. This is important to understand because we're dedicated to bringing a better Cinnamon DE with each and every release but Cinnamon isn't the goal itself, it's just part of it... comes the end of the iteration, we want more, we want Nemo, CC, Screensaver, MDM.. and all that makes a proper Cinnamon edition. As part of our mission to deliver that next environment, sometimes we work really hard on Cinnamon, sometimes we ask developers to give some love to other sub-projects which need more attention. Presently, most of the goals we set for Cinnamon 1.8 itself are implemented, so despite having 50 pull requests open, we're quite happy with the state of 1.7.

  • As much as possible we try to create strong relationships with developers and get "champions" who somewhat "own" parts of the project. This takes time of course and developers get to know each others better and better the more they work together. There's already about 10 people within the pool of Cinnamon developers whose sole nickname is enough assurance for us to know pull requests coming from them are well written and well tested. With time, contributors also get to know Mint and its internal way of working, how we look at things, what our philosophy is when it comes to user interaction, testing, risk taking and innovation. To give you an example, any pull request on the nemo project coming from mtwebster pretty much gets in without much consideration. mtwebster got to the point where he knows nemo better than anyone else, has a deep understanding of its design, shares the vision of what it should be and rarely needs any input from us to make the right call. With a bit more time you'll probably see mtwebster fully step up on the nemo project and he might be the one merging other people's pull requests then.

  • The relationship between Cinnamon and Mint is both a strength and a weakness. You can compare Cinnamon to what it could be on its own, and I'm sure you'd find that it could grow faster. Within Mint it grows consistently towards one direction and fits into a coherent context and integrates with other projects designed to achieve one same overall goal. It's frustrating for people who contribute and only focus or find an interest in one part of the project because that part is held back by all the others, but it's important to get the big picture. What matters are the users and their experience with their computer. This is something we try to improve with each new iteration and our work benefits other projects and other distributions. There's a lot in 1.8 that could have made it in 1.6, but it didn't. It didn't because 1.6 was already exceeding our expectations at the time and so the time was taken away from innovation and put into making sure every single little piece fitted properly. In the end of the day, this is not a race, if you look at projects such as GNOME where some commits where highly controversial, and there was a huge gap between the devs and the user base, I'd say it's as important to innovate as it is to be able to take your time, consider things one by one and maybe sometimes reject contributions which don't fit in with the overall project.

  • Some pull requests get in really quick. We have a roadmap in place and we're often on the IRC to chat about what we want for the next iteration of Cinnamon. When a pull request hits home run by implementing something that's on the roadmap after the contributor talked to the team and his design was approved... things happen really fast. When someone is well-known and championed a particular part of the project things happen fast as well, mtwebster with nemo for instance. When someone contributes something that is independent and brings something new without impacting the existing functionality, things happen fast... Lusito comes to mind here. Also, when people contribute small modular pulls, screenshots, explanations, things happen fast as well. Usually most of the work is done during our chats on the IRC and the implementation that follows via a pull request can be merged easily. The project is doing really well, but it goes through phases, phases of innovation, and phases of consolidation... because in the end of the day, we're not worried about doing the max we can for Cinnamon, we're worried about doing the max we can overall, and sometimes that means doing less when there's enough and putting more focus on making sure everything fits in.

It can be frustrating for contributors, but we're here for that too and we're always happy to chat with people, not only about their contributions or design but also about how they feel. We might lose people and contributors due to that but there's also a great sense of satisfaction gotten from each iteration, knowing that it wasn't all about pace, innovation and doing as much as we could, but having our eye on the overall result that whole time. Looking back at these iterations, I feel very proud of the work done for each one of them. 1.4 and 1.6 lately were huge step forwards and 1.8 is also going to be really impressive. Each of these iterations exceeded our roadmaps, and in terms of planning that almost means too much content and too much focus went into Cinnamon. It's not a nice thing to hear for a Cinnamon developer but our core mission is to incrementally improve the overall user experience, not to innovate as aggressively as technically possible.

I'm sure things will get better with time. That bottleneck will get larger as a few more people will get into the core team and get permission to merge. I hope I managed to explain why this was happening though. It'd be interesting to hear the opinions of the devs here, particularly the ones who contribute a lot to Cinnamon since they probably both understand the Mint rationale behind this and get frustration from it as well :)

We don't say it enough and if we spent the time to answer and acknowledge every contribution we'd be doing users a disservice by not focusing on what needs the most attention... but we're really grateful. Whether it's code, discussions, ideas, bug reports... as you said, they can go unchecked for months, they might not receive any attention... but sometimes some of them are picked up and they make a difference, and the sum of it all allows us to make that system people enjoy using. It can be frustrating for contributors not to get that initial acknowledgment but in the long run most of them know they're the reason why Cinnamon, Nemo, Mint and all the projects they spend time contributing to get better.

This project, this sub-project in fact, is maturing with time. Not only its design and features and how people use Cinnamon, but its team of developers, its pool of contributors and the relationships between them. It's an ongoing process, people get to know each other, and things are slowly but surely getting a little bit faster :) I don't delegate easily and for a project like this one that's both a pro and a cons. I want to make sure things don't go wild and in every direction but there's a definite plan here to welcome new people into the team and to get to a point where some of the developers are able to get things done without me. You all appreciate the size of the Mint project and how it's funded. It works because so many people use it and contribute to it and that allows us to financially maintain a core team of just a few people. For Cinnamon and all other projects, this means a platform, resources, an existing audience, and strict release goals.. but it also means a lot of feedback and contributions to welcome and process and very little time to do so. It's not easy, it leaves a lot of people frustrated, but we can all look at the result and feel proud of the accomplishment... each part could be looked at individually and compared to what it could be if other parts didn't matter.. but they do.

Now with all that said... you don't just want explanations from me here. I promised autarkper to do something about this. I think we're getting close to welcome mtwebster into the core team. Glebihan's work is pristine/perfect but he doesn't always have as much time as people would want. There's a few things that won't change... when it's time to consolidate I'll hold back innovation, I won't multi-track either... but we can improve communication, we can delegate more areas to more people (people were empowered on triaging and nemo in particular) and rather than trying to create "merge parties" (an idea which was good but didn't work out) we'll set up an official weekly meeting on #linuxmint-dev dedicated for merges and design discussions.

@dalcde

@clefebvre I'm blaming your long post for the lack of productivity of Cinnamon developers :)

@clefebvre
Linux Mint member

hehe :)

@galcalde

Have you read this news? Cinnarch will abandon Cinnamon
http://forum.cinnarch.com/viewtopic.php?f=13&t=905

@lockjs

Clem, I appreciate your response, and I'm aware that I'm relatively unknown and only developed anything for Cinnamon in the last month or so, but I have been watching the project with interest since Mint 13, when it finally offered me an upgrade path from Ubuntu 10.10 and Gnome 2 that didn’t seem like a massive compromise in support / changing the way I worked, that said, my 2 cents:

While Cinnamon may be a "part" of Mint it offers, like Nemo the significant opportunity to be more than Mint (imo), you identified the need to retain the traditional use paradigm for computers and built something to provide this, on-top of the adoption of 'modern' technologies, while this can be achieved directly in Gnome-Shell (and the developers now recognize this need [however reluctantly]) Cinnamon offers this paradigm as its core, not a work around. While limiting the project to Mint, or closely tying it, isn't necessarily a bad thing it has the potential to limit both Cinnamon and the other projects as the core team need to devote time to all of them and contributors / developers to each project individually are... overlooked(?) - alternatively these people could be taken advantage of by allowing them to develop Cinnamon more independently of Mint, allowing the core team to focus on other projects which may have less contributor interest - Please note I am not advocating removing Cinnamon from the Mint project (I feel having Cinnamon tied to Mint is perfectly sensible and provides fixed goals as part of a bigger picture for a stable, well integrated system) but allowing it to develop more in the manner of MATE / KDE / XFCE etc where the development isn't controlled by Mint but is incorporated into it, especially in the case of MATE. You have stated that you "try to create strong relationships with developers and get 'champions' who somewhat 'own' parts of the project" perhaps a group of 2-4 champions could be identified for Cinnamon who are given some ownership of the project (ability to merge pull requests) but ultimately buy into the bigger picture for Mint but their focus is on Cinnamon - based on your comments I feel that the bigger picture of Mint may be clouding the smaller picture of sub projects and this may help to re-address this balance while ensure that Cinnamon still meets its core goal - provide a suitable desktop shell for Mint while being usable in other distributions.

I personally wouldn't advocate merging every pull request submitted, I appreciate and accept that there needs to be a defined scope and some developments will fall out of this, or may be better suited to being made available independently as an applet / desklet / extension. That said I feel the view of "we're happy so we don't need to merge anything else until the next release" is perhaps a little off putting - for example Dalcde has submitted a patch with adds comments to the core files and allows for documentation to be auto-generated. This is something that would be incredibly helpful for newer developers, has minimal impact on functionality but has been outstanding for 3 months with no public explanation as to why it hasn't been merged. I would suggest that in most cases contributors new to the project are contributing because 'they' see a perceived need which may have been missed / not implemented due to time constraints by the core team.

While having IRC is useful it is not the "best" form of communication, especially when people are working in different time zones / around other commitments, as such the communication else where really needs to be improved, currently there are 400+ issues open, (~1500 in total) but these aren't organized to any extent, there is no differentiation between Bugs, Feature Requests, things being worked on, things being ignored additionally of the 40 pull requests open there is little feedback, e.g. a message to say "It's been considered but we don't feel its not appropriate to commit at this time". Providing feedback in this manner is beneficial to both the contributor who submitted the issue / pull request and others who can see the project is active and start to build a clearer idea of what will / wont be accepted and what needs resolving / implementing. I accept that this is time consuming but is something that could be handled by a team of Cinnamon contributors with anything important flagged to the core team.

Ultimately I feel the title of this issue is incredibly apt, Cinnamon needs some love, it currently (from the outside) seems to be suffering from some neglect as the priorities of the Core Team are spread amongst a lot of projects. This 'love' could come from increased communication, outside IRC, and engagement with the contributors that have collected around the project.

@bimsebasse

Why do those users and devs impatient with the development pace of Cinnamon not just get together and create a fork?

@Topperfalkon

@bimsebasse I was wondering the same thing.

@lockjs

bimsebasse: unfortunately "well just fork it and do what you like" has become too simple a response if anyone expresses doubt / a contradicting view of a project, neither does it resolve anything.

Personally I don't feel there would be any benefit for anyone to fork Cinnamon, Cinnamon (as far as I can tell isn't a complete DE) it depends on Gnome and other Mint projects for that, perhaps if Cinnamon was little more than a drop in replacement for Gnome-shell you would have seen this already?

Additionally I think ultimately what you are seeing isn't developers unhappy with the direction of the project, quite the opposite, but with the communication and probably positioning of the project and I suspect if you were interested enough to go back to the formation of KDE / Gnome and look at the mailing lists you would see the same kinds of growing pains.

@bimsebasse

I can imagine a scenario where it benefits everyone. Impatient devs have a faster (maybe) growing Cinnamon fork to work on; the current Cinnamon project has a fork it can get ideas and possibly occasionally copy code from, and there'll be less of a pull request bottleneck issue.

Personally I've abandoned tidying up Cinnamon's css and default theme as the few times I've made a pull request it just sank slowly into oblivion. It's not something I'm upset about but it's a shame to think of all the work done on Cinnamon wasted if it doesn't have to be that way.

@hadrons123

Arch Linux most likely will drop cinnamon within a week or two from the official Arch Repos. Its already in the arch-dev-public ML.

@clefebvre
Linux Mint member

Very good points lockjs. I think we're all happy with the pace of cinnamon and if we look at how much it grew in so little time, we can all appreciate this, contributors and users alike. The main problem here is acknowledgment and communication. You said it, there's 40 or so pull requests, some like dalcde's were not looked at for 3 months despite being easy to review and most issues aren't even triaged.

And there's two things at play here... like Mint and many open source projects, we're victim of our own success and as you said we're experiencing growing pains.. where what worked ok before just isn't good enough anymore. What I mean by that is that despite having 4 people able to triage issues (https://github.com/organizations/linuxmint/teams/122275) we've got far too many issues to handle and the communication we used until now (mostly casual IRC chats) just doesn't cut it anymore.

We all agree on the problem here and I'm confident we'll find a solution (I'm also confident this won't be the last time we'll experience growing pains.. whatever solution works now won't work indefinitely as we grow again) :)

Regarding communication, my main concern isn't to increase the quality of the communication but the responsiveness of the core team. In other words I don't want contributors to wait 3 months with no answer anymore. To address this I've set up weekly meetings. Every Monday at 6PM (London time), myself, glebihan and mtwebster will be there for you, for everybody who wants to talk to us, and we'll have one hour dedicated to give people our attention, to discuss designs, to merge pull requests. Of course we do that all the time, you can catch me at any time and ask me to check a pull or discuss a design, but I'm not always there and I don't always have time. That weekly hour long meeting will be specifically dedicated to that. The first meeting is this Monday, it's announced on the IRC topic for #linuxmint-dev and it will come with no structured agenda. We'll use the topic to structure things a bit during the meeting and we might take minutes if content is relevant to people absent in the meeting. If structure is needed, we'll formalize future meetings and get things more organized.. but already we're worried about giving people attention and letting them know we're here for them.

Regarding triaging, we just need more people. We can't separate merging rights from triaging rights on github but there's a lot of people we trust with these permissions not to merge content. We'll ask them if they want to take part into triaging and we'll define tags for issues and ways of working for this. I'm hoping to get started on this today and I'm happy you raised that point.

Regarding Cinnarch, Fedora and probably Debian it's really bad news for users of these distributions. Although my main concern is to make Mint users happy here, making Cinnamon available to the whole Linux community is something that is important to me and I think we achieve our mission when it comes to that. I feel bad for them, but people need to understand the relationship between GNOME/GTK and the GNOME/GTK ecosystem (which cinnamon is part of) and the fact that GNOME/GTK devs do not care about backwards compatibility. You cannot expect Cinnamon to be compatible with the latest GNOME/GTK the minute it comes out, especially if fixing the regressions it creates means losing compatibility with versions of GNOME/GTK we support (compatibility with GNOME/GTK 3.4 is key to us because we're committed to bring new Cinnamon versions to Mint 13 LTS for instance). Our focus is on 3.6 because that's the version we're using and the version we'll be using for the next 6 months. We get pull requests from Fedora and patches to fix muffin and cinnamon for gtk 3.7/3.8 and we're interested in merging them (here again, back to point 1, I want us to be more responsive on this). When a distribution upgrades GNOME/GTK, most of the time, it breaks GTK3 themes, it breaks Cinnamon and it breaks some GTK3 apps. That's because GNOME/GTK is innovating aggressively and they don't consider their ecosystem important enough to guarantee backward compatibility. That's something distributions need to think about when they include the latest GNOME/GTK prior to parts of its ecosystem supporting it. Right now, support for GTK3.8 in Cinnamon is needed by Fedora and we're interested in getting it in, but the driving force behind it is Fedora. It helps us too, it means more people using Cinnamon, more developers (some Cinnamon devs use Fedora) and an early look at what's coming (GTK3.8) for us within Ubuntu/Mint. So it's in everybody's interest that Cinnamon gains GTK3.8 support.. but it's important to understand that this is something driven by Fedora and GTK3.8 users, I'm personally paid to work on Mint, part of that meaning doing my best for Cinnamon to be awesome and GTK3.8 being something I'll be confronted to in about 6 months. We've got the same problem in Fedora.. full time devs overt here aren't paid to work on Cinnamon. So in the case of Cinnarch, I'm not sure the maintainers fully understand the situation when it comes to compatibility between Cinnamon and GNOME/GTK, what I want to say here is that we all want Cinnamon to support all GTK versions, GNOME doesn't make it easy, and nobody gets paid (whether it's in Mint, Cinnarch or Fedora) to make it a top priority. What happened in Fedora, and that's what we do in Mint too, and I'd expect Cinnarch to be able to do it, is freeze upgrades which create regressions and if that's not possible and upstream contributions aren't merged in yet, we patch the software. Leigh's been very proactive on Cinnamon in Fedora, not only sending us pull requests but also actively patching Cinnamon to work great in Fedora independently as well. Maybe it's a case for distro maintainers to be able to contact us more easily and maybe this weekly meeting will help with that too. I feel good about Cinnamon being available to Fedora, Arch and Debian users and they've got both Cinnamon and their distribution to thank for that. There's a bit of responsibility falling on both sides here especially in distributions committed to follow the latest GNOME/GTK without delays and no matter what regressions come as a result. I've no doubt Cinnamon will work great on 3.8 eventually, it's part of my job to make sure it happens for Mint 16, until then I'm more than happy to assist anyone taking the lead on this for whom that support has become important. I'll prioritize the reviewing of the commits related to gtk3.7 to have them done before this Monday (Leigh usually patches cinnamon in fedora though...so we might need a chat with the maintainers of affected distributions here).

Regarding teething problems in general, this project is like a small scale replica of what happens with Mint. The core team is small, there's a lot of contributors, funding is big and the user base is huge. This means we grow all the time, ways of working and infrastructure break often, we achieve a lot, people are happy and contributors are stressed by the lack of acknowledgement but excited to be part of it. It's nothing new... the one thing I learnt from it since 2006 is not to panic and to address things one by one. I think that meeting will help, I think widening the triaging team will help as well, I'm not sure these measures will be enough for now and they certainly won't be enough for later on. We agree on the issues at least, we've got a couple of ideas on how to tackle them... let's see if it works or if we need more.

I know the reason there's so much disbelief is ultimately because people love the project so much and that's very positive. Thanks to all of you for trying to make Cinnamon better.

@clefebvre
Linux Mint member

Regarding distro maintainers, as far as I'm concerned, they're almost part of the team. Their problem is our problem and I'd expect them to talk to us. If anyone out there is sick and tired of patching Cinnamon too much and for merges to take too long, come and tell us. I won't reply to Cinnarch via public blogs, I would have been happy to know what the problem was, whether they tried to patch, whether we needed to merge, or whatnot. I don't remember ever looking at someone and saying "not my problem". 3.8 isn't a priority for us because we're not exposed to it yet, if anyone needs it though our answer is likely to be "how can I help?". Cinnamon is a Mint project and it's the implementation of Mint's vision and needs for a desktop. It's in its design to be compatible with Linux as a whole though, so for it not work or not to be suitable on any distribution is a perfectly valid concern and we do consider it a bug. My main point here is focus and priority. For GTK3.8 support to happen, when most of the dev. team uses 3.6 and GTK isn't backward compatible, the enabler/catalyst here are GTK3.8 users.

@mtwebster mtwebster closed this Jun 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment