The libappindicator Story

Note: This post is part three of a series of thoughts on the relationship between Canonical and GNOME.

Tensions rose this week as claims were made and refuted — mostly as comments on blog posts about entirely different issues! – about the collaboration and relationship between Canonical and GNOME.

After actively participating in much of that discussion, Mark Shuttleworth (founder of Canonical and Ubuntu) responded in a strongly-worded blog post on Thursday morning.

He made a range of claims, but in this part of the series I will focus on his response to the release team’s stated reasons for the rejection of libappindicator:

The premier reason given for the rejection of [Unity's indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

Now, I can tell you that I was pretty disgusted with this result.

Please read Mark’s entire post to get a full appreciation for the depth, breadth and consequence of his criticism.

History

The history of “indicators” is quite long, but as that will be covered in the timeline for part four of this series, I will fast-forward to the introduction of libappindicator itself, during the Ubuntu Developer Summit for Lucid Lynx (UDS-Lucid).

November 18, 2009: Application Indicators are discussed at UDS, aiming to replace the notification area and present a single set of menus on the panel for consistency. The KNotificationItem specification is chosen as a basis for the protocol, but “the addition that we’ll need is the ability to define a menu”.

Actions include “develop the application library”, despite the fact that libappindicator development had already begun, privately, one month earlier (first commit: October 13, 2009). To be fair, it was still pretty raw immediately prior to UDS, but work had clearly begun.

December 3, 2009: The Ubuntu DX team’s ApplicationIndicators wiki page is created. One week later it is updated to include a very thorough set of use cases, architecture documents and a porting guide.

December 16, 2009: Canonical developer Ted Gould blogs about libappindicator, links to the StatusNotifier specification.

December 17, 2009: On the XDG mailing list, Canonical developer Aurélien Gâteau proposes the StatusNotifier specification, a reworking of the KNotificationItem spec first introduced as a draft on September 5, 2009.

January 13, 2010: Ted Gould emails GNOME’s desktop-developer-list (DDL) to request feedback on StatusNotifier. This is the first time libappindicator is raised on a GNOME mailing list. It is already too late to propose for inclusion in GNOME 2.30.

A few technical questions are asked about Canonical’s plan to port applications. Concluding the thread, Dan Winship states: “Anyway, we want a menubar-like tray for GNOME Shell too, and the new spec seems like a good plan.”

January 18, 2010: Dan Winship responds to the StatusNotifier proposal, raising his concerns about the specification, spawning a discussion almost exclusively with Aaron Seigo (which I will cover in another post).

(So rereading this, it comes across as kinda harsh, but it wasn’t supposed to be, so just add a “:-)” to the end of every line or something. :-)

February 6-17, 2010: Canonical developers blog about Application Indicators — including Jorge Castro’s Application Indicator Update, Jono Bacon’s KDE Application Indicators in GNOME and (contractor) Jan Arne Petersen’s Application Indicators – all of which note that patches for application support are already being submitted upstream, ie. GNOME’s Bugzilla.

February 15, 2010: The new module proposals period opens for GNOME 3.0.

February 18, 2010: Colin Walters, a Red Hat developer working on GNOME Shell, raises Canonical’s application indicators work for discussion on DDL.

First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here.

His questions revolve around how applications should use it, how it might fit in with the design plans for GNOME Shell, and suggests that it would make sense for the API to live in GTK+ rather than a separate library.

Ted Gould and Jorge Castro participate in the resulting 11 post thread (there was another subthread, but irrelevant to the proposal itself). Matthias Clasen contributes two grumpy points about Canonical’s approach to collaboration (not designing in the open and asking GNOME developers to discuss API issues on the Ayatana list).

Roughly 6 hours after his last post in that thread, Ted Gould proposes libappindicator as an external dependency for GNOME 3.0, strongly emphasising that the discussion focus only on its inclusion as an external dependency. He includes the key question about the library, raised earlier: “Does this fit the the design goals for GNOME Shell?”

Olav Vitters of the release team suggests that question must be answered before the release team can make a decision. Ted replies, “Obviously that’s a question that I can’t answer. Though, one that I’d love an answer and a discussion about.”

A concern is raised about copyright assignment, and there’s a silly little subthread about versions of the GPL (much less likely to be a problem than the CLA).

The meat of the thread is a discussion about libappindicator’s use of GTK+ menu APIs, with suggestions from GTK+ developers for how to improve the libappindicator API.

Discussion peters out, without answers to the fundamental questions, with Ted Gould having sent a total of 5 emails to a 17 post thread. (Cody Russell also contributed, but not about technical issues.)

March & April, 2010: Two and a half months (Feb 19–May 6) pass without a single discussion about libappindicator on any GNOME mailing list.

Intermission! Let’s take a moment to recall Mark Shuttleworth’s comments about why GNOME developers rejected libappindicator:

Much of the language, and much of the decision making I’ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome.

The premier reason given for the rejection of [Unity's indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

What made this single statement heartbreaking for me to see was that it spoke clearly to the end of one of Gnome’s core values: code talks. Here we had API’s which were real, tested code, with patches to many Gnome apps available, that implemented a spec that had been extensively discussed on FreeDesktop.org. This was real code. Yet it was blocked because someone – a Gnome Shell designer – wanted to explore other ideas, ideas which at the time were not working code at all. There’s been a lot of commentary on that decision. Most recently, Aaron Seigo pointed out that this decision was as much a rejection of cross-desktop standards as it was a rejection of Canonical’s code.

It’s also saying that Unity is not “in GNOME”. Clearly, a lot of Unity work depends on the adoption of these API’s for a smooth and well-designed panel experience. So once again, we have a statement that Unity is “competition with Gnome” and not “competition within Gnome”.

Intermission over.


May 6, 2010: Last call for comments on module proposals. Dan Winship, a Red Hat developer working on GNOME Shell, replies to the libappindicator proposal with the final word on its relevance to the new shell:

The system status area needs numerous features that aren’t available in libappindicator [...] so libappindicator will not be useful here.

As for the trayicons in the message tray [...] the StatusNotifier protocol that the appindicator work is built on is just… designed to solve some problem other than ours. I still think we don’t want libappindicator.

So while Dan doesn’t think libappindicator fits with GNOME Shell’s system status or notification goals, he doesn’t close the door entirely to StatusNotifier/dbusmenu (the XDG protocol guts wrapped by libappindicator):

And at any rate, since gdbus will be landing soon, if we did want to support the StatusNotifier/dbusmenu protocol, we could just add that to GtkTrayIcon now.

Ted Gould replies, “Not to criticize your decision, but just to correct a couple of factual details in your e-mail”, noting that dbusmenu is included in KDE and the StatusNotifier spec, and that libappindicator would be ported to gdbus soon. He doesn’t object to Dan’s decision. There is no further discussion.

May 10, 2010: Mark Shuttleworth reveals the Unity netbook user experience to the world during his opening “keynote” at UDS Maverick, and writes about it later that day:

Unity and Gnome Shell are complementary for the Gnome Project. While Gnome Shell presents an expansive view of how people work in complex environments with multiple simultaneous activities, Unity is designed to address the other end of the spectrum, where people are focused on doing one thing at any given time.

May 16, 2010: The GNOME release team meets, and based on the feedback received, decides to reject libappindicator for GNOME 3.0.

June 2, 2010: The release team announces new module decisions for GNOME 3.0, stating the reasons why libappindicator is rejected as an external dependency.

No Canonical developers reply.

Excluding vala-list discussions about wrapping the API, there is a grand total of five pages of Google results for “libappindicator” in the GNOME list archives.

Understanding the decision

Mark is not a day-to-day participant in the GNOME community (he does run a company, after all), so it’s easy to understand why he has so misunderstood the process and motivations of the community – through the lens of the release team’s rejection reasons.

Let’s go through them:

  • it doesn’t integrate with gnome-shell

I hope I have demonstrated absolutely clearly in the timeline above that libappindicator was not rejected due to a sense of “competition” between Unity and GNOME Shell: The key advice to the release team was given four days before Unity was unveiled.

  • probably depends on GtkApplication, and would need integration in GTK+ itself

Unfortunately, this point is badly written, but it’s related to the suggestion that the API should actually be in GTK+ rather than a separate library. It demonstrates that while the library – conceived and designed without technical or strategic advice from the GNOME community — was rejected, the ideas behind it were not. Mailing list discussions reflected the same view, as shown above.

It’s important to recognise that this is not the behaviour you would expect of those who would discriminate against Canonical, or who had already made up their minds a long time ago.

  • we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen

Mark’s response to this was, “We made the proposal, it was rejected.” Well, yes… but keep in mind that he is quoting the rejection itself! :-)

I can tell you that the people who worked on the proposal consider themselves Gnome people, and they feel they did what was required, and stopped when it was clear they were not going to be accepted. I’ve had people point to this bullet and say “you should have pushed harder”.

I believe the timeline above clearly demonstrates that Canonical did not do “what was required”. Unpaid volunteers regularly do more to get their work into GNOME than Canonical did in this case. I can barely describe how little effort was invested pursuing this proposal.

Ted Gould is not at fault, by the way. If Canonical wanted it done, it could have assigned different people to the task, more people to the task, or anyone at all during March and April.

The flip side to this is that Aurélien Gâteau engaged with the KDE community early and often in his work to update specifications to reflect Canonical requirements, bring in dbusmenu support, etc. I don’t believe the key difference here is between GNOME and KDE, it is in Canonical’s approach to engagement, and its commitment of developers to the task.

  • there’s nothing in GNOME needing it.

Mark’s response:

This is a very interesting comment. It’s saying “no Gnome apps have used these API’s”. But the Gnome apps in question were looking to this very process for approval of their desire to use the API’s. You cannot have a process to pre-approve API’s, then decline to do so because “nobody has used the API’s which are not yet approved”.

This is a simple misunderstanding: No process exists to “pre-approve APIs”. So that’s not the process libappindicator was submitted to… or rejected by.

Any GNOME module can add an optional (or “soft”) build dependency at any time. Jorge, Jono and Jan even blogged about libappindicator support patches being sent upstream… prior to the proposal!

An “external dependency” in GNOME release parlance describes a particular version of a library that is not maintained by the GNOME community, but acceptable as a required (or “hard”) dependency. DBus is a good example: it’s not a GNOME project, but we can rely on a particular version’s API, ABI and protocol being consistent.

The irony is: libappindicator did not need to be listed as an external dependency for Mark to have achieved his goals. Canonical needn’t have engaged at all! (Sure, that would have created all sorts of different problems…)

Conclusion

Mark’s extraordinary criticisms were made without understanding the process, without understanding the quotes he was using as evidence, and frankly, without understanding the GNOME community’s motivations or intentions.

Key points:

  • Canonical barely made an effort to have libappindicator “accepted into GNOME” (which, in the context of his criticism, Mark believed was important or necessary)
  • It did not even need to go through this process anyway, because it did not need to be an “external dependency” in order to achieve Mark’s stated goals (ie. application adoption of the API)
  • So the rejection of libappindicator, for all the sturm und drang, is essentially meaningless — it had no bearing on the opportunity for collaboration between Canonical and GNOME
  • Unity did not exist in the public sphere when libappindicator was declared irrelevant to GNOME Shell, and was not ever the reason why: (a) there wasn’t much interest in libappindicator, or (b) GNOME Shell developers decided they were on a different path
  • Not proven in this part of the series, but worth noting: the person Mark specifically chose to attack, Jon McCann, did not decide to exclude libappindicator because — being a design contributor to GNOME Shell — he felt threatened by Unity. In fact, he had no part in the decision, and didn’t know Unity existed!

But libappindicator is just one chapter in a much longer story… see you in part four! :-)

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

This entry was posted in General and tagged , , , , , . Bookmark the permalink.

97 Responses to The libappindicator Story

  1. Dam says:

    I’m afraid a timeline extracted from archives is not going to transcribe how people felt about their perceived involvement both in public or private discussions. From previous blog posts it seems that events you find significant don’t match what other participants would. Even factual events can be highly subjective depending on the perception people have of them and of their consequences.

    In the end Ubuntu or KDE people honestly think they did their best to integrate with GNOME in open ways and obviously GNOME people think this was neither done properly nor openly. Both points of view seems irreconcilable in the short term and from my experience any further discussion on past event is unfortunately only going to deepen tensions and to polarize communities even more.

    Best would be to concentrate on points of converge and on actions that can be taken to prevent this from happening in the future. For instance both involved parties seem to agree that FreeDesktop.org structure or processes need major improvements.

    • Jeff Waugh says:

      I’m afraid a timeline extracted from archives is not going to transcribe how people felt about their perceived involvement both in public or private discussions.

      But if it clearly refutes the thesis of a complaint…

      • zekopeko says:

        No it does not refute the complaint. You are ignoring exactly what is the core of the problem here and what Dam noted. And that is that “a timeline extracted from archives is not going to transcribe how people felt about their perceived involvement both in public or private discussions”.

    • Jeff Waugh says:

      Oh, I should also point out that I don’t regard this post as an answer to the issues that Aaron raised about KDE and freedesktop.org — I will cover those in a different post. This was purely about Canonical and GNOME.

      • ScottK says:

        You can’t separate this discussion into two clean pieces.

        I was in the November 2009 UDS session and there were non-Canonical Gnome people in the session (sorry, I don’t remember who a year and a half later). Two points from that discussion:

        1. The notion that this was a surprise to Gnome is ridiculous. There were Gnome people present at the foundational discussion that occurred at the beginning of your timeline (I think the notion that some code having been written several weeks before is somehow sinister is a reach).

        2. My recollection of their reaction was outrage that Canonical would consider technology developed by KDE for Ubuntu.

        I’m not known as a shill for Canonical and I really don’t think your timeline proves anything. The fact that it fails to note there were Gnome people at the UDS session suggests this is incomplete at best. I think that fact undermines your thesis.

        • Jeff Waugh says:

          I don’t think libappindicator was a “surprise” to GNOME. Discussions at UDS with select GNOME developers (often sponsored by Canonical) do not serve as collaboration with the GNOME community though.

        • Vincent Untz says:

          I was one of the GNOME people in this session. And I remember explicitly mentioning that I wasn’t sure about the technical design and that it should be discussed upstream to be sure it’s the right way to do this.

          I don’t remember the outrage you’re mentioning, though. But could be because of selective memory :-)

          • ScottK says:

            It could have been me filling in my expected reaction. I do remember people who weren’t familiar with the spec having questions. Re the timeline discussion this is in the middle of the alleged two year radio silence so I think it’s significant to the thesis even if I got the emotions wrong.

            • Jeff Waugh says:

              Canonical built quite a bit of stuff during that two year silence! I will be writing about this in an upcoming post.

              A discussion at UDS is not a method of collaboration with GNOME. No designs were proposed on the GNOME wiki, or raised on the GNOME mailing lists — not even completed, unchangeable, “we think this is perfect” ones. Where were the module proposals during that time, even the “we’re dumping finished code on your lap” ones? These are the methods of collaboration you would expect in any other project.

              Canonical simply didn’t do it.

          • Jef Spaleta says:

            Was that particular UDS session recorded? I know historically there have been some efforts to video archive UDS sessions.

            -jef

          • ScottK says:

            Not sure about the comment threading, trying to respond to Jef Spaleta…

            I don’t remember it being recorded, but it was awhile ago. I’ll see if I can find the notes from the session.

            • Jeff Waugh says:

              Sorry, there’s a depth limit. Perhaps I should change that for the next week. ;-)

            • Jef Spaleta says:

              Yes…a while ago. That’s part of the problem. Anything you can do to point to any personal summaries of events or an audio recording of the Q/A would be great boon.

              -jef

              • ScottK says:

                I don’t have any notes from that session. My recollection was that the agreement with the Gnome devs that were there was that follow-up discussion would happen on the FDO list. From the timeline it appears that happened, it just didn’t get to a useful conclusion.

                I will add that the descriptions of how Gnome work sound a lot like how KDE works. Personally I consider the appearance of a Qt/KDE implementation in upstream KDE at the same time the Gnome implementation appeared in Ubuntu as significant evidence that Canonical was willing to cooperate where cooperation was there to be had.

              • ScottK says:

                I didn’t say it was. I meant (and I thought this was obvious) an implementation based on Gnome technologies). Based on the fact that Canonical and KDE managed to jointly develop and deliver an implementation into the next KDE upstream release, it’s clear they were interested and capable of collaboration. I know that doesn’t fit your thesis, but it’s what happened. I think I’m done with this thread as it’s pretty clear you’ve decided what happened.

                • Jeff Waugh says:

                  Yes, Aurelien worked within KDE to push the changes. No such effort was made on the GNOME side, until libappindicator was proposed. But then… it didn’t provide the user interface side of the equation for either the GNOME Panel or GNOME Shell. They were interested and capable of collaboration, but simply didn’t do so.

          • Jef Spaleta says:

            Vincent,

            Did you perhaps write up in personal notes of your time at UDS and rebroadcast them on a gnome relevant mailing list? I think I sort of remember you making a blog post. If so can you reach back and provide a url reference.

            -jef

  2. Sekar says:

    Thanks for this post. Enlightening to say the least.

    http://waughpartners.com.au/ is down btw.

  3. anonymous says:

    From your timeline, to be honest it sounds like Canonical “Did the Right Thing” here. GNOME seems to have had ample notice about Canonical’s plans.

    • Tim says:

      Even though its hard to see how anyone could reach that conclusion from the timeline above, communities can’t function just by giving each other ample notice. They have to give ample notice, then work together.

  4. bombo says:

    blablabla whocares, just merge the patch, for users’ sake.

    See Owen Taylor’s post about the issue instead of feeding the flamewar sir, it may be a better use of your time

  5. fatal says:

    Personally I think much of the problems is in Marks/Canonicals “take it or leave it” attitude vs. the general (Gnome) “you got to be prepared for a lot of reworking based on careful review” attitude.
    (Anyone with a clue about software development knows several iterations are needed in the process for good software.)

    IMNSHO Canonical simply doesn’t have enough “street creds” to have a “take it or leave it” attitude. People will simply ignore anything proposed with such an attitude in most opensource projects….

    … and I think in the long run it will hurt Canonical more then anyone else if Canonical gets ignored.

    I think Canonical will learn how to work with/in open projects, but the stubbornness of them thinking they’re already the center of the universe will make sure it will happen later rather then alot of people probably hope/wish for. Signs of these stubborn moves are things like copyright assignment with a false claim that Canonical is the major contributor (even Nokia figured out copyright assignment isn’t going to be accepted for gods sake!), trying to integrate something into a stack with a new license and agressively pushing for new licensing suiting Canonicals needs rather then whats best for the stack they’re integrating with, etc….

    //fatal

    • jg says:

      Couldn’t agree more. This is part of what I call the “Ubuntu Uber Alles” mindset that permeates everything surrounding Ubuntu/Canonical. The ubuntu folks are so obsessed with trying to get Ubuntu to be the next Windows (with a MacOS theme) to every consumer on the planet, that _everything else_ is secondary (to the point of often being inconsequential). Whether it’s taking from upstream and giving little back, standing upon the shoulders of FOSS in order to promote its own walled garden (UbuntuOne, LaunchPad), criticising everyone else while so vociferously seeking to silence criticism of Canonical/Ubuntu (and remember the “respect website” fiasco?), skimming donations from a FOSS non-profit in order to fund its private corporation, requiring copyright assignments to a corporation when accepting “donations”, etc, one has to see that ultimately the long history of Canonical/Ubuntu “mistakes” (ie, “misunderstandings”, whatever) aren’t just that. They’re actually the result of so many FOSS entities having so little in common with that “Ubuntu Uber Alles” mentality.

      The only sure-bet prediction is that Canonical/Ubuntu will make lots more of these “mistakes” as its own goals trample all over the very different goals of those many, many FOSS entities that Canonical/Ubuntu relies upon to even exist.

  6. Killerkiwi says:

    removing the politics and hurt feelings, this is all I see…

    *ubuntu indicators/KDE and gnome systray don’t work with the same API*

    Come on guys work it out are we going to have to write code for 2 systems for the next 5 years? A little compromise on the API from what ever side and this all goes away

    • KDE, GNOME-Shell, gnome-panel, Unity all support the existing XEmbed based systray spec.. Status Notifiers are for a new pure-dbus technique.

      • Markus S. says:

        The upcoming Unity 11.04 or 11.10 won’t be compatible with legacy XEmbed systray icons.

        • Jeff Waugh says:

          I believe the desktop team has pulled Mark away from that particular cliff… 11.04′s Unity certainly supports XEmbed.

          • Markus S. says:

            Yeah, I should’ve been more specific: The idea was to support it on a technical level, but gradually block all applications that are not on a shrinking whitelist.
            I don’t know the timeframe but the proposed outcome was to eventually block everything except Java and Wine.

            Personally, I think it’s the right move. First blocking KDE apps from using XEmbed would make sense as starting point because Plasma has the StatusNotifier specs implemented first, thus KDE developers had most time to port it over.

  7. Frej says:

    Unity and Gnome Shell are complementary for the Gnome Project. While Gnome Shell presents an expansive view of how people work in complex environments with multiple simultaneous activities, Unity is designed to address the other end of the spectrum, where people are focused on doing one thing at any given time.

    That seems to be a pretty big misconception of gnome-shell?

  8. antistress says:

    thank you for this really detailled & balanced article, very instructive

  9. ulrik says:

    The Gnome-shell team themselves have been insular for all this time and has not engaged with the community to evaluate their design.

    I’m also seeing the “we need a different solution” argument a lot, but it not worth so much after gnome shell implementing its status notifiers almost the same way.

    (I don’t use ubuntu)

    • jonner says:

      That’s simply untrue. They’re no more insular than any other team within GNOME. The fact that GNOME Shell made some decisions that you don’t like does not necessarily mean they’re insular. It simply means that they’ve made some decisions that you don’t like.

    • @ulrik: the gnome-shell and gnome-design team have been exactly the opposite of insular. all discussions, every decision has been made in the public — including considerations and adjustments in the design. obviously, within a series of time constraints: you can’t ask in January, with a UI freeze date set, to overhaul the appearances of the Shell; it just won’t work.

      now, from my position as a spectator on mailing lists and IRC channels, all I can say is that a lot of contributions from the community were either incomplete, vague, unsupported by fact or logic except the “this is my workflow”, or just plain crack. lots of mockups done with gimp and inkscape have been inflicted upon the design team, and they have been far, far more graceful in handling them (and especially the insults) than you’d be expecting by people that have a day job and are doing this as a side project, in their own time. it takes a huge amount of effort and time to deconstruct even the most simple and well-explained proposal for a change in a user interaction model: interaction design is science (another thing that the vocal minority doesn’t seem to accept, or think that is not important), but it’s not code that you can pass through a validation test suite. and I can assure you: I’ve seen very, very few simple and well-explained proposals. most of the time it was a huge pile of junk that made me want to gauge my eyes out with a rusty spoon.

      so, what you mistook for insularity is actually the result of the fact that the Shell and Design teams are not huge, are mostly volunteers, and don’t have the time to address every single mockup or proposal in the time constraints imposed by the development cycle. but, and herein lies the nice bit: it’s the first development cycle of many. GNOME 2.x had 15 development cycles; 3.x will probably have fewer before 4.x — but it still means that what’s not ready yet will be ready in the future.

      • bugreporter says:

        Well, usability can only be evaluated with the (almost) finished product. As far as I see the user interface is still undergoing changes.
        I reported issues via Bugzilla in January/February – I didn’t expect that fixes will go in for the release in April. The answer was in short:
        “This issue are reported to late to be considered.” (Implicitely admitting that there is indeed an issue).
        I was redirected to IRC (Isn’t Bugzilla to tool to track bugs?)
        Bug has been marked as “fixed”!
        The usability issues are still there. There is plenty of time to fix the issues for the next release. This is not exactly what I expected as “community feedback is welcome”.
        Don’t take me wrong, there are many thing I like about Gnome3 – but I fail to see how community feedback is actually welcome.
        Are the results of the usability tests documented, somewhere?

        • Numpty says:

          “Well, usability can only be evaluated with the (almost) finished product.”

          Absolutely not true, and you’re setting yourself up to fail if you haven’t done any usability evaluation before things are nearly finished. Usability begins right at the task and requirements analysis stage, which can only be properly written with input from users. It then goes through various iterations of user feedback on low fidelity (e.g. paper) prototypes, before you’d normally even think about putting them in front of something that’s running on an actual computer.

          • bugreporter says:

            Agreed, usability testing should start early in the design process. However it should not stop in the middle of the process! Anytime you change your user interface you should check usability again.
            If user feedback on usability issues are not welcome on Bugzilla, then this should be stated somewhere.
            To me as an outside-user the whole process is completely in-transparent. As I understand it, user feedback (via Bugzilla) on usability is not welcome (right now).

    • bkor says:

      ulrik: They have. And you can interact with them.

  10. nmota says:

    Reading your blog, this post, your comments on Mark’s blog and others it seems to me that you are being naive. :)
    There were and are mistakes being made by both parts, GNOME and Canonical, in terms of interoperability and communication between each other and between them and the community of users and developers.
    Nonetheless I need to ask you a question: Whom do you think as the most to lose with this state of things? (I mean Canonical developing Unity and pushing the Ayatana thing, among others, outside GNOME)

    • Jeff Waugh says:

      Whom do you think as the most to lose with this state of things?

      I’m not fully sure that’s relevant to my point, or particularly interesting in itself, but I will answer something approximating that question later in the series.

  11. zekopeko says:

    I see a number of issues with this post.

    First of all is the infamous McCann and Gould talk in 2008 in which it was apparently informally agreed that the panel need cleaning and it was implied that Canonical would do it. So Canonical went to work thinking they are doing a good thing that will be accepted in Gnome.
    Gnome can’t pretend as if they didn’t know that appindicators where being developed in the open since a number of posts from Ubuntu folk landed on planet.gnome.org talking about indicators.

    Next, appindicators where rejected May 16, 2010 but Unity was unveiled on May 10. After that you have the relayout re-design of Gnome Shell at GUADEC, nearly two months after Unity’s unveiling. You would have to be extremely dishonest not to notice the uncanny similarities between Gnome-Shell and Unity in that mockup. Take this in the light of some 30+ threads on the GS mailing list where users complained about the original design and Gnome people vigorously defending it for nearly 2 years. Come Unity and somehow they decide that their, up to that point “perfect”, design needs some re-designing.

    The whole “nothing in Gnome is using it” non-argument is also rubbish. Indicators where welcomed in the broader community and plenty of apps are using them or would use them if they where part of the platform. The same applies to Zeitgeist. They could have rejected the Activity Journal which is pointless but should have accepted the underlying framework.

    So from the outside it does look like a clique intentionally blocking adoption of indicators. Canonical could have pushed harder for inclusion of indicators. But Gnome could have and should have participated more in the StatusNotifiers specification talks and should have engaged with Ubuntu more. They are accusing Canonical of not playing by Gnome’s rules but they are unwilling to do so when their “upstream” (all of the non-Gnome community) makes something that will help cross-desktop integration.

    The majority of blame is on Gnome and their broken way of doing things.
    So today we have two major desktop shells using a cross-desktop standard and one ignoring it.

    • Jeff Waugh says:

      First of all is the infamous McCann and Gould talk in 2008 in which it was apparently informally agreed that the panel need cleaning and it was implied that Canonical would do it. So Canonical went to work thinking they are doing a good thing that will be accepted in Gnome.

      I will deal with this in a later post, but the key issue here is (as Mark himself has said): Code talks. A suggestion that work would be done TWO WHOLE YEARS ahead of proposal for inclusion, without any collaboration in the mean time is… not the way Open Source development works. :-)

      Next, appindicators where rejected May 16, 2010 but Unity was unveiled on May 10.

      The key input in the decision to reject libappindicator was delivered on May 6. Unity simply wasn’t relevant to the decision.

      So, I’m sorry, but you are mistaken.

      • Jimmy Smiths says:

        You’ve made it perfectly clear how Gnome makes it difficult to communicate.

        Right now, you’re speaking, ostensibly, on behalf of Gnome. Telling us “you don’t understand, this is how Gnome works”. The concensus, at least outside @gnome.org, is that it works BADLY. You argue you’re great at collaborating, yet the people who wish to collaborate with you think otherwise. You think you’re open, others think you’re insular. Case in point: Canonical HAS to work in Gnome git, but Gnome devs can’t be bothered to use Launchpad. It’s beneath them.

        If it’s only about public record this, archived timeline of that, and no consideration to actual communication, this isn’t a community. It’s a bunch of divorce lawyers. Because divorce is on the cards. And Ubuntu is the single biggest source of the one thing Gnome lacks most: users.

        If there was silence for those “TWO WHOLE YEARS”, it’s probably because Shuttleworth thought he had your word (your as in Gnome’s) and TRUSTED you. And now he feels that trust was ill-placed. Without trust, marriages fail.

        • Jeff Waugh says:

          I’m not speaking on behalf of GNOME. I’m not saying that GNOME is a paragon of collaboration — read the previous post in this series!

          If there was silence for those “TWO WHOLE YEARS”, it’s probably because Shuttleworth thought he had your word (your as in Gnome’s) and TRUSTED you.

          But the only way you could believe that is if you had a fundamental misunderstanding of how Open Source works. Those two years were not about trust, they were about a complete lack of communication and collaboration. That’s not how things get done.

          • Jimmy Smiths says:

            Actually, it looks like plenty got done. By a larger, more transparent community with more vision and better leadership, that is closer to its users and listens to them. At least that’s what it looks like to me, and many the other fans of Gnome who took the time to comment in this debate.

            It might not be what you think. It might not be an accurate reflexion of the complex, distributed power-dynamics of open-source. But it’s detrimental to Gnome. And NO ONE in Gnome has accepted any of the blame, aside from maybe Dave Neary. Who wasn’t really to blame.

            See, I don’t really care about the shell, or the indicators, really. I care that a project I WOULD like to get involved in – with my real name no less – is so unwilling to recognize any of its fundamental problems – let alone tackle them. You guys are actually DEFENDING your behaviour.

            You know how long I tried to compile The Shell only to realize that they were targeting a version of X that was only available on Fedora Rawhide, because it hadn’t even been released yet? Advice on IRC: “well, install Fedora”. How’s that for encouraging participation?

            • Jeff Waugh says:

              so unwilling to recognize any of its fundamental problems

              Did you read the previous post in the series, Thoughts on GNOME? There’s a lot of recognition-of-fundamental-problems over there.

              Canonical clearly goofed with this proposal, and the funny thing is, it really didn’t matter if libappindicator “got in” anyway. I’m not so much defending GNOME behaviour as pointing out obvious errors with Mark’s extraordinary accusations. (And remember, I don’t speak for GNOME.)

              You can build GNOME Shell on Ubuntu natty, by the way. It’s bleeding edge software, and happens need a very recent version of X. So what?

        • Markus S. says:

          Sorry but when you want to develop something for GNOME, use gnome.org and not Launchpad.

          Aurelien Gateau from KDE and Canonical once wrote in an email that Canonical has the policy that own development has to happen on Launchpad.

          • Jimmy Smiths says:

            Yes, they developed their own. And then proposed it to Gnome.

            Answer: NIH

            Hey, I already have a repository set up, and don’t have a @gnome.org e-mail/git access yet. Should I just stop programming, and tracking revisions, altogether, until I gets annointed? Should I wait until everyone’s chimed in on how my icons aren’t in the right place before I get anything going?

            My way?
            Highway?

            • Jeff Waugh says:

              No, that’s not really the point. It was not rejected because it was conceived, designed and developed in private — those just happened to contribute to the reasons for which it was rejected. It’s not a matter of NIH. I think this will be more clear after my next post, by the way.

            • bkor says:

              That was not the case.

            • Markus S. says:

              No matter if hosting was a reason in this case or not:
              If you develop something in order to make it become part of GNOME at some point, you should be willing to upstream the code from your private repo to gnome.org, use GNOME’s bug tracker, etc.

              My comment was not made for the specific appindicator case but show a general pattern: Canonical forbids its employees to fully approach upstream projects.
              Canonical employees and upstream projects can’t negotiate on equal grounds because Canonical employees are not allowed to give up copyright assignment and Launchpad.

              GNOME has no problems with cross-desktop frameworks being hosted somewhere else. Zeitgeist, which IIRC will be fully integrated into GNOME 3.2, is also hosted on Launchpad.
              Mono is hosted somewhere else as well.

        • bkor says:

          Canonical didn’t communicate with as. Furthermore they really misread the release-team decision. Release-team has received no clarification request up to now. Only blogs and so on. The archives are public btw. If they had concerns/issues, why not raise them with us instead of silence and then after a long time some blogposts?

      • zekopeko says:

        You completely ignored the core of my comment. Gnome’s actions after the indicators rejection are the main problem. They declined KDE/Ubuntu based technology (as per ScottK’s comment and numerous comments from other KDE developers) and then they re-designed GS to look almost exactly like Unity. From outside it doesn’t look good.

        You keep defending Gnome but it is obvious to outsiders that the organization is in serious need of reform.

        • Jeff Waugh says:

          Gnome’s actions after the indicators rejection are the main problem.

          Well, that’s not what Mark is claiming. :-)

          Today, still, GNOME Shell developers are open to the prospect of implementing the StatusNotifier specification. It’s just not appropriate so close to the release of 3.0. So “KDE/Ubuntu based technology” wasn’t declined. A small library (not at all relevant to implementing the specification in Shell) was rejected.

          And again, I do not claim that GNOME is perfect, merely that Mark has not provided an accurate representation of history, Canonical’s attempts to collaborate, or the GNOME community’s attitude towards collaboration.

          • zekopeko says:

            What Mark said exists in a context. Stop pretending like your timeline is irrefutable proof. You have to look at other things that aren’t in your timeline. AFAICT Mark did provide an accurate description of events.

            The main problem here is Gnome’s handling of outside contributions and general sentiment among Gnome developers. If it didn’t come from Gnome it’s rejected unless they need it for some part of their project.

            Their handling of rejections pretty much shows what is wrong with Gnome. Instead of engaging with the developers of proposed modules they simply reject them without any explanation.

            It took Seif Lotfy to make a ruckus around the rejection of Zeitgeist for somebody from Gnome to explaine why it was rejected and how it can be fixed so that it’s included in GS.

            • Jeff Waugh says:

              I’ll deal with some of Mark’s other claims in an upcoming post, but it is absolutely clear now that libappindicator was not excluded because of Unity.

            • bkor says:

              “It took Seif Lotfy to make a ruckus around the rejection of Zeitgeist for somebody from Gnome to explaine why it was rejected and how it can be fixed so that it’s included in GS.”

              It was explained in the release-team announcement email. Seif misunderstood the decision and got a bit emotional. So I contacted him and explained things.
              As in the GNOME code of conduct: Assume we mean well.. because we do.

        • Frej says:

          Why does it not look good?

          Either they didn’t copy, or they did. I can’t see what’s wrong in either case. And you can’t force others into saying they took your idea when they believe the opposite. But is that a really such a huge issue?

          I’m not saying they did copy, i’m saying it doesn’t matter.

    • Markus S. says:

      You can’t blame GNOME for not accepting libappindicator at that time.
      When Canonical halfheartedly proposed it for GNOME inclusion, only patches for the classic 2.xx Panel were provided and none for GS.
      2.xx was already reaching End Of Life and adopting new technology in an EOL product, when the successor is not compatible with it, is insane.

  12. lelamal says:

    Boy, was this enlightening! With your posts I finally start to understand the other side of the story. And without any rhetoric tribalism or that illuminated leadership yadda-yadda. Thank you!

  13. Vadim Peretokin says:

    So we see that GNOME is being on the defensive about it’s (lack of) leadership and the actions the whole body together somehow took.

    This isn’t the most pleasant thing to be seeing, especially as a supporter.

    • Jeff Waugh says:

      If you think exposing the truth is being defensive, then OK. :-)

      I would point out that the GNOME community, and specific individuals within it, were attacked. Very strong accusations were made. That members of the GNOME community disagree with Mark’s thesis is clear. It would be strange not to see responses to that effect.

      Note that I do not speak for GNOME.

      • Vadim Peretokin says:

        You’re only speaking for the individuals involved, who are GNOME, so you aren’t speaking for GNOME but are speaking for GNOME?

        I understand it has been pointed out by GNOME members that GNOME has no leadership and thus doesn’t really exist as a body, just a collection of individual members – who are somehow getting through the pathway of life by deciding this or that, accepting this or that, or doing this or that. But it still is a collective of some sorts, no?

        My point is – I’m not understanding how are you not speaking for GNOME when you seem to be. Are you trying to be an outside observer of GNOME, while being in GNOME?

        • Jeff Waugh says:

          I left Canonical in July 2006. I haven’t been an active participant in the GNOME community since December 2008, when I resigned from the GNOME Foundation Board of Directors. I am an outside observer with… keen insight… into both organisations. :-)

          • Vadim Peretokin says:

            Okay. So what I draw now is that GNOME is a disorganized community without a leadership, with people making the calls that affect the whole community here and there, and now this captainless ship has run into trouble with other communities.

            Combined with reasons pertaining to the Shell, complete ignorance of Ubuntu by gnome.org since forever, and now somehow wobbly vision of “we’re right, you’re wrong, we aren’t changing our plans for your ideas, oh and we’re taking away Compiz too” I’m cancelling my GNOME friendship right now. Never got used to Fedora, never got used to OpenSUSE, Ubuntu’s work on GNOME is only what made it usable and now this public spat – I might as well put my tiny token of support elsewhere, because I can’t get behind such embarassing activities.

            • Jeff Waugh says:

              Well, none of that reflects reality, but do whatever you feel is right.

            • Jeff Waugh says:

              This is almost certainly a pointless “someone is being wrong on the Internet” reply, but I want to clear a few things up.

              complete ignorance of Ubuntu by gnome.org since forever

              Canonical developers have been welcome to contribute their major changes, but haven’t. Those Canonical developers are in a different group (the DX team) to the Canonical developers who package, integrate and fix bugs in GNOME every day (the distribution team).

              Day to day collaboration between GNOME developers working on the various distributions, whoever they are employed by, is great. Everyone benefits from it. Canonical have just been really terrible at contributing major chunks of work, which is damaging to them and the community.

              “we’re right, you’re wrong, we aren’t changing our plans for your ideas”

              The libappindicator stuff is not evidence for this, but that’s hard to explain without completing my next post (which explains what libappindicator actually does, and why it wasn’t relevant to GNOME Shell)… but yes, there is a certain hardness of vision from late 2010 through to now, while GNOME 3.0 was intended to ship.

              Remember, much of the vision for it was laid out in 2008. Anyone could have got involved through 2008-2009 when a huge chunk of the difficult, post-conception design work was done. Once we hit 2010 and 2011, radical changes were far less likely to happen.

              But don’t worry… GNOME 3.0 is the start of a whole new adventure, and GNOME Shell will change as much over the next nine years as GNOME 2.0 did during the previous nine years.

              “oh and we’re taking away Compiz too”

              You can continue to use Compiz with the classic GNOME interface (which has been maintained and updated alongside the development of GNOME Shell) if you like. To achieve the user experience conceived for GNOME Shell in 2008, a much more integrated approach was necessary. The shell is actually a plugin for the window manager. Very different kettle of fish!

            • Markus S. says:

              “we’re taking away Compiz too”

              Oh come on.
              Both GS and Unity walk on exactly the retarded path to develop a desktop environment as plugin for a specific window manager.
              GS can’t be used with anything but Mutter and Unity (beginning with 11.04) can’t be used with anything but Compiz.

        • Jeff Waugh says:

          But it still is a collective of some sorts, no?

          GNOME is an open, independent, meritocratic, co-development community. It is supported by the GNOME Foundation which is a formal, US-based, non-profit 501(3)c.

          (Things you should know before you make claims!)

  14. Vadim Peretokin says:

    The thing doesn’t nest enough, so I’ll reply here. Before I start, thanks for writing that!

    gnome.org ignorance – I didn’t mean the developing side of it. I meant gnome.org. You visit there, and it’s as if Fedora is the only GNOME user around. Want to try the latest GNOME? You get a Fedora OS. Um? I don’t want to deal with a different set of tools, and asking to support the most populous userbase shouldn’t be too much, is it?

    Compiz – no, it’s not a different kettle of fish. I need my Compiz plugins – zoom (the way it works), colour invert (the way it works), ADD plugin (the way it works). For me, as a user, that functionality is necessary. GNOME Shell is removing it, and hence, I can’t use the Shell. Unity is like the Shell, and Unity supports this (okay, not the wobbly windows, but I guess I’ll have to do in order to have the snapping work). Sorry for the dumbified argument, but I’m interested the in features and functionality, not why is it so technically or the fact that I’ll be without it for half a year and then it’ll be re-added if it will be. Hence the Shell, so far, is dissapointing – and was so from the start.

    This is why I’m mildly frustrated and ceased my support.

    - “random GNOME user on the Internet”

    • Jeff Waugh says:

      gnome.org ignorance – I didn’t mean the developing side of it. I meant gnome.org. You visit there, and it’s as if Fedora is the only GNOME user around.

      I honestly don’t understand what you mean here (links would be good). The website has never strongly favoured one distribution over the other… people would get cranky about that very quickly. If there’s some reason you think it does, then it should be fixed. You could help fix it by reporting a bug, or offering to help with the content.

      GNOME Shell is removing [Compiz], and hence, I can’t use the Shell.

      GNOME Shell is not “removing” Compiz. Because GNOME Shell is essentially a window manager itself, Compiz simply isn’t relevant. Compiz was never shipped with GNOME, but some distributions chose to use it. It happens to be used in Unity, but that was not always the case. Had the Canonical DX team helped with Mutter and Clutter (they didn’t have the engineering experience to do so), you’d be complaining that Unity had taken Compiz away too!

      If you want to keep using Compiz, you can keep using the “classic” GNOME user experience. If you want the GNOME Shell user experience to reflect some of the things you like about Compiz (the features you’ve mentioned), you’ll need to get involved. Have you talked to the developers about your concerns / desires?

      (Keep in mind that GNOME 3.0 is very close to release, so major changes simply aren’t appropriate. The Shell developers can explain why something is a major change or not. This isn’t a matter of not caring about user input, it’s just part and parcel of actually shipping software.)

    • Vincent Untz says:

      “You visit there, and it’s as if Fedora is the only GNOME user around. Want to try the latest GNOME? You get a Fedora OS.”

      Errr… Go to http://www.gnome3.org/tryit.html and you’ll get something based on openSUSE (with most of openSUSE branding stripped out, because what we’re promoting here is GNOME, not openSUSE). So, hrm, I’ll disagree with your comment that it’s just Fedora stuff :-)

      If your point is that there’s no Ubuntu image, or whatever, then I’m sure we’d all welcome an Ubuntu image if somebody steps up to create one.

    • Frej says:

      You know, you don’t have to click on the upgrade button? It’s actually possible to use keep using version x if x+1 doesn’t suit you, and wait for x+2.

      PS: gnome-panel still exists, even in gnome3. Just use that?

  15. A disappointed user says:

    It seems like GNOME 3.0 was not going anywhere when the Shell project came out, instantly making it the de facto future of the project.

    Back in 2005, GNOME was very promising, Planet GNOME was a pleasure to read and technical leads were both respected and respectful. 6 years later, I’m really sad to notice that the lack of vision and leadership and the misplaced egotism of some developers completely undermined the project.

    • Jeff Waugh says:

      GNOME Shell was the beginning of serious efforts on GNOME 3.0. Prior to Shell, it was just an ongoing background discussion, and a mish-mash of thoughts and ideas.

  16. camaron says:

    @ jeff

    Do you know how many core developers form the gnome shell team?

    • Jeff Waugh says:

      Matthew Garrett made a code/contributor comparison between GNOME Shell and Unity at the time Mark announced Unity would form the default user experience in Ubuntu 11.04. Obviously that’s out of date now, but it gives you some idea, particularly at the moment of announcement. I’ll provide updated numbers in a later post.

      • camaron says:

        If you were second-guessing me you’ve done an amazing job as that is the exact information I was looking for :).

        -So 100% of Unity code is by Canonical (no surprises eh?)
        -91% of Gnome-shell is by Red Hat: now, this is something.

        Canonical are often accused of being very good at spin (and they are not bad indeed) but it seems to me they are just start-up amateurs compared to Red Hat. In the last few days of the-hell-has-broken-lose I don’t remember once Red Had being mentioned as part of the equation. Gnome-Canonical-KDE but where is Red Had here?

        The obvious question is: is Red Hat share of decision-making entitlement somehow correlated to its share of code?

        • Jeff Waugh says:

          Red Hat has been raised in the context of the debate: Mark thinks GNOME and GNOME Shell are “owned” by Red Hat, that Red Hat defines the strategy. That’s simply not true. Yes, they’ve invested in GTK+, GNOME and GNOME Shell, but they don’t control them.

          • camaron says:

            That is a bit of a easy answer, isn’t? To say that Red Hat doesn’t define the strategy when they write MOST of the code.

            I think more honest would be to try to see exactly (OK, more or less) HOW MUCH of the strategy they control. Just as a reminder: Red Hat are a big software corporation, their main desktop investment is Gnome, which is moving onto Gnome-shell of which they have written most of the code. To represent this conflict as a conflict between another corporation (canonical) and a bunch of free-software developers that come together to develop Gnome is not right. Talking about spin, eh?

            Jeff, don’t get me wrong: I could’ve brought this up in any of the blogs I’ve painfully read in the last couple of days; nothing particular to you. This is just the last one I came across and it was about enough for me.

            • Jeff Waugh says:

              GNOME Shell was conceived as a GNOME project in October 2008. It was designed and built from scratch, in the open, since then. Anyone could’ve got involved. It is very much not a Red Hat project. It’s a completely open GNOME project.

              (And again, this will be the subject of a later post.)

              • camaron says:

                I see,
                it just happens that Red Hat were SO much more interested than anyone else that they managed to produced 91% of the code,with no strategic influence whatsoever in the day to day growth of the project.

                I see

          • I have to be careful about how I phrase this, but, hem…it would be best to think in terms of lots of GNOME Shell developers happening to be employed by Red Hat than in terms of Red Hat controlling (or rather, wanting to control) the development of the Shell.

            If you look at it objectively, you might conclude that GNOME Shell really isn’t of much strategic value to Red Hat as a corporate body, and I would say that’s not an incorrect conclusion. You might want, as a thought experiment, to ask yourself the questions ‘how strategically important is Unity to Canonical’ and ‘how strategically important is GNOME Shell to Red Hat’, and compare the answers.

            Yes, a lot of the Shell developers work for Red Hat; but this doesn’t mean that the relationship of Red Hat as a corporate entity to the Shell is the same as the relationship of Canonical as a corporate entity to Unity. A nice way (I hope, for both parties) to put it might be that Red Hat sponsors development of the Shell, while Canonical directs development of Unity.

        • Markus S. says:

          Grow a brain. 91% of the code is from Red Hat but not 91% of the people involved in GS are from Red Hat. Full-time developers just program more than hobbyists.
          http://www.bomahy.nl/hylke/blog/96/

        • Alfred Wilburton says:

          You’re edging close to a very important point: Canonical could take a leadership position in GNOME but has chosen not to do so.

          Red Hat encourages their developers to create projects in the open on public mailing lists, to hang out in GNOME’s IRC, to develop in upstream’s version control systems, to use upstream’s bug trackers. Because their developers are paid to be available 9-5 every day (and probably more), they end up wielding an enormous amount of influence. Red Hat’s developers become maintainers of important modules, they become members of the release team, they become the go-to people in any technical decision making. Their developers become respected, well-regarded members of GNOME.

          Canonical does not encourage that sort of contribution. Their developers are encouraged to work in Launchpad with bazaar, not on gnome.org with git and Bugzilla. If Canonical would push their developers to work as closely with GTK+, glib, and other GNOME technologies upstream as Red Hat does, Canonical could wield all the influence they wanted. Influence is proportional to the amount of work you’re willing to put in.

          Canonical has a choice! Their developers can become maintainers too! They should become maintainers! The GNOME community desperately wants Canonical to step up and take charge upstream. They desperately want Canonical to be so closely involved with GNOME development processes and release schedules that Canonical developers become members of the release team. So far, that isn’t happening.

          If Canonical wants to influence GNOME, they can do so, but they can’t do that by standing outside and shouting instructions. They must lead from within.

  17. Rod Greening says:

    I remember the movie Jerry McGuire and Cuba’s famous line “Show me the money!”.

    In this case I’d like to scream out “Show me the process!”.

    Here’s my full blog post regarding such…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments will be sent to the moderation queue.