A typical day in my life as of late

I will cover the following from a very high-level view (I’ll have to make separate blog posts to cover them in detail, there’s too much to say):

• The state of our multimedia stack
• Our new timeline canvas and how you can help
• This year’s accepted Summer of Code projects
• Upcoming GUADEC presentation

Also, a small announcement: for those who also want some shorter, less formal status updates and occasional feedback probes, you can look at the new PiTiVi G+ page.

Clutter timeline canvas

In preparation for the Summer of Code, but mostly just to help us and demonstrate how much of a badass he is, Mathieu Duponchelle killed our goocanvas-based timeline and redid the whole thing with Clutter. In two weeks. This is what it looks like at the moment:

The state of our multimedia stack

We fixed some initial bugs in GNonLin in Milan. Since then, further investigation revealed that most of the issues we are encountering are actually generic bugs in GStreamer. Mathieu is now working full time on fixing bugs everywhere in the stack. We hope to have something showable (beta) for GUADEC and a release this fall — as you can imagine however, I’m unable to make solid promises at this point.

There are still many things that we need to rearchitect in GNonLin, but that’s a story for another blog post.

We recently started using Github’s bug tracking tool to keep a more easily manageable list of issues we have to deal with in the development version. Please note:

• This is not a replacement for GNOME Bugzilla. It is meant as a temporary measure for our extended development version, for stuff that is too small, fluid or uncertain to be filed as proper bug reports. Once we release, we’ll move remaining issues to Bugzilla. Upstream issues in GStreamer, once properly identified, are always filed in GStreamer’s (GNOME) Bugzilla.
• We welcome your help in fixing or investigating these issues. There’s also an “easy” tag for those of you looking for bitesized stuff.

Stuff you can fix in Pitivi, right now.

If working on GStreamer and GES is not your cup of tea, we still have a ton of fun little projects for you to do on Pitivi itself, including:

• A bunch of little nitpicks/papercuts for our Clutter timeline
• During the port to Clutter, Daniel Thul helped Mathieu by rearchitecturing and fixing the timeline clip thumbnailer module. It works, but there are some remaining, significant performance issues. This is a great project if you’re looking for finite, concrete, self-contained work to improve performance with a very highly visible impact on the UI. You would get a ton of love points for this.
• We have a title editor UI, but it needs some love. You don’t want us to ship with an unrefined UI, do you?
• UI tests!

This Summer of Code’s projects

We have four students working on Pitivi this summer, thanks to GNOME kindly offering us an extra slot to be able to achieve our mission. Here’s our ambitious list of project goals:

• General bug fixing in the entire GStreamer + GES + Pitivi stack, to be able to make a Pitivi release.
• Motion ramping (keyframable fast/slow motion, allowing the speed of clips to be changed over time, ideally with smooth frame interpolation)
• Finish the enablement of our new timeline layers management UI
• Reimplement audio waveforms. Better, faster, stronger.
• Video compositing
• Proxy editing. I’m currently writing a design and API requirements brainstorming page to help plan this feature. I will share it in my next blog post, where I’ll present some of the dilemmas I’m encountering (particularly around codecs).

Presenting at GUADEC

Come to GUADEC and attend my presentation at the beginning of August. Plans are a bit fuzzy for the time being, but you can expect my typical award-winning presentation style. Also, as usual, we’ll be having a Pitivi hackfest there. Czech it out.

• …at the beginning, with the progressbar saying it’s currently “estimating” — which was a lie that I corrected a little while ago.
• …at the very end. Extra trolling points for having made you waste a huge amount of time to get a 0 bytes output file (if we’re lucky, that bug is gone).
• …somewhere in the middle, because caps negotiation failed, some elements were not linked, GStreamer thinks you ran out of available RAM, or because you’ve been very naughty.

In any such case, the rendering dialog just sat there and smiled at you, as if everything was fine in the world. Well, no more:

Pitivi is going to give you the honest, brutal truth.

This is the result of a horrifying thought suddenly springing to my mind yesterday night: “Hey, what if the code was not even checking for errors in the pipeline when rendering?”

Indeed, it wasn’t. How silly is that! I have thus prepared a simple fix to improve the situation: catch pipeline error messages, abort the render (you really don’t want to ignore a GStreamer error) and display an error dialog. This will at least let people know that something is wrong and that they should start writing patches to GStreamer instead of accusing Pitivi of hurting kittens. You’d be surprised how many people can sit for hours in front of that stuck progressbar.

Before I commit the fix however, I would need your feedback on the usability of that dialog:

This is not terribly pretty, but it’s better than nothing. A few things to consider:

• In that screenshot, all the text except the window title (“Error While Rendering Project”) comes from the GStreamer pipeline error message (the error and the error’s details). I know that the error details look ugly, but I suspect it wouldn’t be useful to GStreamer/Pitivi developers if we don’t have them “verbatim”. Maybe we could try to mangle the error details string (split using “:” and take only the first and last two items of the resulting list?) and encourage the user to run from a terminal to get better debug info, but that feels a bit backwards.
• We should probably have some less-scary text to accompany the actual error details. Something that guides the user towards an action that can be done to address the problem (ex: reporting a bug). Maybe it can be placed between the header and the details (above the “qtdemux.c” line)? The problem is finding a universal text to be used.
• If we consider the route where we suggest the user to report bugs, where should we point to? The Pitivi bugs investigation page? Pitivi bugzilla? GStreamer bugzilla? The distro’s bug tracker?
• Let’s keep this simple, both visually and in terms of code/implementation.

What do you think? Is the current approach sufficient or is there something better that we can easily do?

Update: here’s an alternative dialog with some more comprehensible text, where the actual error (as seen in the previous screenshot) gets shoved under the rug by putting it in a GTK expander widget (clicking “Details” reveals the error’s details as above):

One way to look at things is that there is no such thing as a PiTiVi backend anymore. PiTiVi is a frontend that pushes the latest and greatest open-source multimedia technologies forward.

With the GES port nearing completion, this is the first time that we can truly say there are three interrelated components to contribute to. This new reality sets the tone for a different way to look at PiTiVi project ideas this year: you can finally…

Choose your character class

Are you a ninja? A spellcaster? A tank? While most projects are a balance of backend and UI work, we know that some people prefer to lean more to one side or another of the continuum — that’s why I created a new visual notation for our ideas page this year. Instead of an “easy/hard” system (which would be inaccurate and misleading, as perceived difficulty is measured differently for everybody), we simply provided a visual indication of the expected involvement in the various components for a given project idea (for example, “PiTiVi: ◼◼◻◻◻ GES: ◼◼◼◼◼  GStreamer: ◼◼◼◻◻”). So if you were looking for something closer to a hardcore GStreamer GSoC project, you can spot ideas that might interest you here.

Not a programmer? You can help raise awareness about this. Maybe you know a brilliant hacker friend/relative or a top-notch computer science student waiting for a chance to make a big difference in the world. Tell that person about how cool and welcoming PiTiVi is and how getting involved is the best way to advance free, powerful and intuitive video editing for everyone!

The core feature was to watch webpages for updates: back then, I did not know about syndication feeds, and I was sick of refreshing ifolder.com every single day hoping for a release of the peer-to-peer version of iFolder (for which we still have no equivalent today).

But why stop there? Why not handle events such as new emails, network failures (in those days, I ran my web server on my flaky residential connexion), software updates becoming available, and so on? You can grasp the whole genius of the idea by looking at one of the first mockups I drew back then:

Some old-timers among you may have noticed a ressemblance with Beagle‘s old user interface — back when it was called “Bleeding-Edge Search Tool”. Aaah, another nostalgic memory of the Novell desktop days.

Specto taught me that even if you have an arguably brilliant concept/mockup, random strangers on the Internet won’t magically jump onto your bandwagon and write code for you. Once this “reality check” finally set in after a couple of months, I took the dive and taught myself Python programming. Specto holds some sentimental value as it was my first OOP learning platform, but I’d probably be horrified if I were to look at its code now, after having considerably improved my skills by contributing to Pitivi. How the hell can Specto have nearly as much code as the current Pitivi development version, anyway!?

But I disgress. Where was I? Ah yes.

GNOME 3.6 made it all obsolete — finally.

The thought struck me recently: the user experience provided by GNOME Shell’s notification system is exactly what I needed all along. It fills my desire to have my computer patiently wait — like a tireless companion — for my return, without worrying about missing events.

If someone had shown me GNOME 3.6 in 2005, I would not have believed it. And yet, with the gradual changes in the 3.x series, we sometimes forget how fantastic the whole thing is.

Even with my heightened expectations, I was still impressed to see that I could now pick up calls even if my home desktop computer’s screen is locked! A real technological delight.

For watching the Web, Specto is now mostly irrelevant: Liferea is the program that took its place in my life. Arguably, social networks have also filled that role for many people.

Sometimes, the software you created becomes irrelevant and you find that to be a good thing.

Following up on my previous announcements where I called for a new maintainer and subsequently decided I wouldn’t touch anything without a patch, I can now say this in light of GNOME 3.6: Specto is dead. I don’t care about it anymore. Of course, if someone wants to take over maintainership/direction of the project, I’ll gladly give that ability to you.

Image de Chandler Reed, citation d’un livre que vous connaissez sûrement

Au-delà de l’Internet

Pour commencer, je n’ai jamais eu confiance envers le pouvoir médiatique. De ce que j’avais pu conclure du visionnement de Manufacturing Consent: Noam Chomsky and the Media, ainsi que mes réflexions dans mon parcours scolaire, j’étais à la base vacciné. Le tout m’a été confirmé comme étant un phénomène bien réel au printemps 2011, lorsque j’ai vu des choses capitales être sciemment auto-censurées par Radio-Canada et toute la presse francophone québécoise. Par son écrasant pouvoir, le système médiatique a alors réussi à renverser le gouvernement en place, sur une histoire que les journalistes savaient fausse (« mais on s’en fout, ça fait notre affaire, si je vais à contre-courant je vais me faire crucifier sur place de toutes façons »).

Tout ça pour dire que je prends tout ce qu’on me dit avec une grande dose de scepticisme et de questionnement. Ce qui compte n’est pas ce qu’on me dit, mais comment on me le dit ou ce qu’on ne me dit pas. Assez contextualisé maintenant, amorçons le sujet du jour.

Les tabloïdes du libre

Je croise parfois des gens qui jurent par certains sites de nouvelles pourtant reconnus parmi les cercles des « faiseurs » (de logiciels) comme étant des tabloïdes, c’est-à-dire de « presse à sensation », de la presse boulevardière, de la fiction pulpeuse. Étant donné l’immense pouvoir d’influence que détiennent ces sites, leur rôle semble donc osciller entre « alliés » et « épines dans le pied ».

Avec une déconcertante régularité ils se fourvoient, créent de fausses rumeurs, discréditent certains projets libres et font l’éloge de certains logiciels propriétaires (tant qu’ils sont excitants et « shiny »).

Je cite ici les principaux coupables que j’observe régulièrement:

• Phoronix
• OMG! Ubuntu
• Slashdot, dépendamment du moment et des commentateurs. Je lis Slashdot (seulement la catégorie Linux) principalement pour les commentaires parfois hilarants et souvent déprimants. Au final, la majorité des nouvelles « à sensation » ou visant à créer la controverse… émanent de Phoronix, qui les poste sur Slashdot pour avoir du traffic.

Il y en a sûrement plein d’autres dont vous pourrez me faire mention, mais pour l’instant j’aimerais simplement donner ceux-là en exemple.

Phoronix: le site où M. Larabel poste en moyenne 8 à 12 articles par jour (!), typiquement en s’auto-spammant de liens vers ses propres articles et en soumettant chaque controverse à Slashdot pour le plaisir des barbus qui ont une dent contre projet XYZ, la Free Software Foundation ou autre.

On me dira que l’intérêt principal de Phoronix, c’est ses bancs d’essais de matériel. En théorie, c’est effectivement intéressant d’avoir un site centré sur le matériel pour Linux. En pratique, cependant:

• Habituellement, les résultats annoncés sont statistiquement non significatifs. Dans à peu près tous les articles par exemple, vous verrez une ou deux images par seconde de différence (sur un total de 30, 50, 100 images par seconde) pour un test graphique XYZ entre deux distributions, ou encore une demie seconde de gain de vitesse de compression d’un fichier d’archive qui prend trois minutes à décompresser… bref, des nombres et des graphes vides de sens dans le « monde réel », qui permettent toutefois de générer des articles constamment.
• La méthodologie de mesure de la Phoronix Test Suite est à vérifier. J’étais excité de faire mes propres tests avec PTS lorsque le pilote libre r600 est apparu circa 2010, mais j’ai découvert par le fait même que les résultats n’avaient absolument rien à voir avec ce que je mesurais dans la réalité! En effet, j’obtenais, en testant manuellement au lieu d’utiliser PTS, plus de deux fois le framerate dans Urban Terror avec les réglages graphiques au maximum, alors que la PTS les réglait au minimum. Depuis, je n’ai plus confiance en la représentativité des mesures de PTS. Si on peut me prouver que ce n’est plus le cas de nos jours, j’en serais plutôt content.

Bref, il y a fort à douter sur les mesures effectuées par la Phoronix Test Suite lors des bancs d’essai. Ce qui nous laisse alors la deuxième partie du site: les « actualités »… et là, c’est pas joli à voir. De mémoire récente:

• Les sondages (aux échantillons non-représentatifs de la population) qui servent d’exutoire aux diatribes et permettent d’affirmer que tout le monde déteste passionnément GNOME [1, 2]
• Ciel! Fedora 19 va utiliser Cinnamon comme environnement de bureau par défaut, et inclure le kernel FreeBSD! Excepté que ce n’était pas vrai, ce n’était qu’une idée lancée aléatoirement sur une page de wiki.
• Des mentions à répétition au fil des années comme quoi Lightworks est un « logiciel open source » (même à l’intérieur des autres nouvelles concernant Openshot, Cinelerra, Avidemux, etc.)… ce qui est encore à ce jour faux. Soit, la vaste majorité des sites Internet commettent la même erreur… Est-ce que Phoronix admet l’erreur lorsque quelqu’un se donne la peine de l’indiquer, cependant? Non monsieur. On poste un nouvel article qui place le blâme sur l’autre, en l’intitulant « Lightworks Is Not As Open As Some Would Like » (emphase ajoutée) et en terminant l’article par une mention insinuant que, de toutes façons, les logiciels libres dans le domaine sont tous à chier. Bon, moi, au final, ça ne me fait ni chaud ni froid, je préfèrerais d’ailleurs ne pas donner en exemple un tel article de Phoronix qui pointe vers un de mes propres billets de blog — ça donne faussement l’impression que je tiens une rancune personnelle envers Phoronix, ce qui n’est pas le cas. J’utilise cette anecdote seulement pour illustrer comment les rédacteurs de tabloïdes tordent les mots pour nous faire dire n’importe quoi et se déresponsabiliser autant que possible. Si ça peut vous rassurer, le cas ici était relativement isolé, comparativement à ce qu’on voit tout le temps de la part de Sam Varghese chez ITWire, par exemple.
• Apparemment, qu’un illustre développeur de KDE poste un billet énonçant son scepticisme face à l’approche de Canonical concernant le Ubuntu Phone constitue, aux yeux de Phoronix, du bashing. N’oublions pas le link-spam obligatoire à travers Slashdot. Dans l’instance présente, les commentateurs de Slashdot ne sont pas dupes.
• « Tiens, pourquoi ne pas rappeller que projet XYZ n’avance pas? Si on peut essayer de discréditer la FSF, tant mieux! Alors si c’est pas pour rhâler envers l’état des logiciels de montage vidéo, autant basher Gnash parce que ces maudits hippies ne travaillent pas assez vite ». Et pour s’assurer de bien éclabousser la FSF, on va vous pointer vers de multiples liens d’articles internes similaires qui continuent la longue lignée.

OMG! Ubuntu: ne rentrons pas ici dans l’énumération exhaustive des nombreuses histoires à sensation et de « hype » autour de logiciels propriétaires ou n’existant même pas… observons simplement quelques perles récentes:

• Un article originellement intitulé « Photoshop CS2 available for free, works fine in WINE »… suivi du « Oups, en fait on a sauté dessus la nouvelle avec l’empressement habituel, c’était complètement faux ».
• Un joli petit vox populi après avoir diabolisé Nautilus 3.5+. Pas étonnant que tout monde ait vu rouge vu le traitement honteux que OMG! Ubuntu en a fait. Je cite: « Amongst the features you will find missing in the version of Nautilus (now renamed ‘Files’) are ones you may have used on a daily basis, including:
  • Compact View: removed
  • ‘Type Ahead Find’: removed
  • ‘New file’ templates: removed
  • Application Menu: removed
  • ‘Go’ menu: removed
  • F3 split screen: removed
  • ‘tree’ view: removed
  • Bookmark menu items: removed
  • Backspace shortcut to return to parent folder: removed
  • [...]
  • Default icons size set to 32px
  • New date-list view
  • Folders no longer sorted by default
  • Floating status bar »

Effrayant et révoltant, n’est-ce pas? Sauf que le tout a été volontairement rédigé de cette façon pour amener le lectorat à bondir d’indignation. Parce que si on prend le temps de réfléchir à l’effet global de ces changements, et qu’on se donne la peine de suivre les liens vers les commits que OMG! Ubuntu citait… on se rend compte que tout ça est plein de bon sens dans l’ensemble:

• Certains éléments de la liste n’ont en fait pas été enlevés, juste remplacés par quelque chose de mieux ou affichés uniquement au moment opportun. C’est le cas du « type ahead find », du « new file templates » (ben ouais, pourquoi montrer un menu quand il n’y a pas d’items dans ~/Modèles?)
• Application Menu removed, ‘Go’ menu removed, Bookmark menu items removed, etc.: tous le même truc, vraiment. Entièrement sensé. Ça s’appelle… se conformer au design du reste de l’environnement! Nautilus est le gestionnaire de fichiers de GNOME, n’est-il donc pas normal qu’il s’y intègre de la même façon que les autres applications « core »?
• Pour monter d’un dossier dans la hiérarchie… le raccourci officiel/standard a toujours été « Alt+↑ ». Je devine que le retrait du raccourci Backspace était pour améliorer la cohérence avec les autres applications comme Epiphany et pour empêcher les conflits avec la nouvelle fonctionnalité de recherche.
• Les véritables changements: le « treeview » a été remplacé par un « listview », la barre latérale a été simplifiée (et s’en trouve franchement plus robuste) et le mode « split panes » a été retiré. Ils étaient ridiculement buggés et ne me manquent pas le moins du monde, mais je suis probablement un des rares à penser celà. Sur ces points là, ça ne me dérange du tout qu’on soit en désaccord avec moi, c’est un débat légitime. Soit. Quand on y pense, c’est quand même pas la fin du monde.

…Le tout suivi d’articles indiquant que c’est tellement un désastre que Ubuntu pense à boycotter le nouveau Nautilus, si si ils y pensent vraiment.

Après ce genre de couverture médiatique « amicale », il y a eu du damage control obligé [1, 2] pour éviter un attentat à la bombe… Ce qui n’a pas empêché OMG! Ubuntu de continuer à jeter de l’huile sur le feu. Parce que la situation n’était pas déjà assez tendue.

Je vous épargne d’ailleurs un argumentaire assez long sur les principes d’échantillonnage et de validité statistique — principes que les sondages retrouvés sur les tabloïdes ci-haut ne peuvent fondamentalement pas respecter concernant des sujets controversés comme GNOME (le seul moyen serait d’avoir un échantillon véritablement aléatoire et représentatif aux allures d’un référendum planétaire).

Au final, puis-je vraiment les blâmer?

Les journalistes sont humains et ont essentiellement un travail de merde dans un monde de plus en plus frénétique.

Et là, je vous évite un bloc de texte immense, parce que quelqu’un a déjà fait tout le travail d’analyse de « pourquoi les journalistes se comportent comme ça!? » à ma place. C’est assez volumineux, mais allez voir cet article éventuellement: Cheap Tabloid Tricks: The Truth About Linux, Open Source And The Media.

La fin du monde annoncée sous diverses formes n’a pas eu lieu.

À en croire les sites de nouvelles, Nautilus 3.6 est un désastre, l’installateur (Anaconda) repensé de Fedora 18 est un désastre, et il y a une conspiration pour saboter nos logiciels favoris.

Pourtant, j’admire les améliorations et raffinements apportés à Nautilus 3.6 et je suis ravi du nouvel installateur de Fedora 18. Dans le cas de Nautilus 3.6, j’ai refusé de juger un logiciel par la mauvaise presse qu’on lui donnait et ai préféré donner la chance au coureur et l’essayer moi même, ce que OMG! Ubuntu ne s’est pas donné la peine de faire. Après un mois d’usage, je me sens plus à l’aise avec 3.6 et me sens irrité quand j’utilise la version 3.4. Clairement, je dois faire partie d’une minorité de mollusques fanatiques zélés qui accepte n’importe quoi. Je dois être fou.

Nautilus 3.6, le mangeur d’âmes nocturne

La lecture des commentaires est, vous le devinez, bien plus nocive que la lecture des articles: même quand un geek on ne peut plus conciliant se donne la peine d’expliquer pendant 55 minutes, de façon calme et raisonnable, les malentendus autour de projets controversés comme GNOME, la première chose que les gens vont faire sur Internet c’est de dire « De toutes façons c’est un connard, j’ai arrêté d’écouter à 7 minutes parce que ça me plaisait pas ». Tous des fascistes qui n’écoutent pas ce qu’on a à dire, ces développeurs!

Tout ça me fait présager que lorsque la prochaine version de Pitivi sortira (« un jour »), les commentateurs du net trouveront sûrement plein de choses pour dire que c’est un désastre. Même Joey de OMG! Ubuntu n’avait que ceci à dire lors de l’annonce de la dernière release d’Openshot: « Meh. » (traduction: « Bof/bah. »). Mais c’est pas grave, c’est l’Internet, personne ne sait que vous êtes un chien, et on s’en fout des sentiments des développeurs à l’autre bout, ils sont grands et costauds, ils s’en remettront!

Pour conclure

• Les sites de nouvelles similaires à ceux mentionnés précédemment ne doivent pas être considérés comme des sources fiables pour se former une opinion.
• Lire les critiques sur ce genre de sites est nocif pour votre bien-être mental. Spécialement si vous êtes un contributeur au Logiciel libre. Là-dessus, je vous recommande la lecture de ce billet de mon pote Federico (oui, ce Federico là). Rien de révolutionnaire, mais quand même une lecture intéressante pour comprendre le phénomène du blues du hacker. Des fois, les développeurs libristes souffrent également de dépression sévère [1] [2] [3]. Heureusement pour moi, ce n’est pas mon cas, je suis typiquement optimiste.
• Plutôt que de vous demander « Qu’est-ce qu’on me dit? », questionnez-vous toujours sur « Qu’est-ce qu’on ne me dit pas? », « À quel point les sources sont pertinentes? » et « Où est-ce que ça rentre dans le grand ordre des choses? »

How about we revive the Performance wiki page and make it a goal for GNOME 3.8 (or 3.10) to finally reach our 2005-2007 target of a “3 seconds login time”?

Our current login performance is pretty bad. We do way too much I/O and processing. If you write an application or service that automatically starts at login, please take a long hard look at how much extra work you’re doing on a cold start. It might seem small, but it all adds up very quickly with the rest of the applications competing for resources, as you can see in the bootcharts I made for that bug report:

This is not a new problem. It’s been there since the GNOME 2.x days and has not vanished (as I hoped it would) with the GNOME 3 session. It’s something that we have to tackle and solve together, as a well-integrated desktop environment and application ecosystem.

See for yourself: log-in on a 3-5 years old computer or netbook/nettop (not on a Core i7 with a solid state drive!), and you’ll feel the pain. And then, at the other end of the spectrum (a modern computer with a SSD), we should probably have the goal that login takes 0.5 seconds or less.

Pour vous donner le contexte, j’écrivais cette note personnelle dans Tomboy en 2006, suite à la lecture de Getting Things Done:

Nostalgie? Tout à fait. Maintenant, retour vers le futur, où ce problème est résolu par GTG.

Avec la version 0.3, GTG vient de se sortir de la pire crise de development de son existence. En effet, la version 0.2.4 datait de 2010 (faisons fi de la version intermédiaire 0.2.9 qui n’a pas vraiment eu le temps d’être reprise par plusieurs distributions Linux). Un très long cycle de réingéniérie—pas qu’un simple réusinage, non mossieur !—s’est effectué entre 0.2.4 et 0.3. Le résultat est une application qui performe mieux, est plus facile à développer et lave plus blanc. Je vous laisse constater les prouesses de la nouvelle mouture. La liste de bugs réglés par la série 0.3 (incluant les améliorations de 0.2.9) est tellement longue qu’elle fait planter Launchpad. Selon mes estimations, le total se situe à environ 400 bugs résolus (excluant les doublons, invalides, etc).

Puisque je suis maintenant un vieux crouton après toutes ces années d’utilisation intensive de 0.2.4 (malgré ses petits défauts), je ne suis pas encore passé à 0.3 sur ma machine principale—j’attends que ça vienne avec ma distribution Linux. Toutefois, selon mes quelques tests, le tout me semble solide. Je vous invite donc, jeunes chenapans, à utiliser cette nouvelle version de toute urgence, et m’en donner des nouvelles.

Évidemment, je vous invite également à contribuer au projet. Ploum et ses comparses vous aideront certainement à vaincre les monstres de l’espace qui pourraient croiser votre chemin.

It is very hard to find any relevant prior art that could guide me for this metaphor (most applications don’t have icons for these, they are only available through menu items). Inkscape can get away with icons that show “drag handles”, but we don’t have those in Pitivi. (un)grouping is quite an abstract concept, given that it does not visually change the clips in any way, it just changes the way they react to selections.

The last two items in the image below are the current group/ungroup icons:

Here is my attempt at making new ones with clearer meaning:

What do you think? Do you have better ideas on how to represent this?

Note: the icons I made are pixel-perfect, the 1px black lines above the icons are not my fault (I think). GTK seems to add some sort of shadow, probably because it expects symbolic icons in that toolbar (but I can’t imagine a way to represent clip interactions without color).

Recently, a significant piece of the puzzle has been fully solved in PulseAudio 2.0: real, rock-solid acoustic echo cancelling. Echo cancelling is not to be confused with echo concealment/suppression, which is basically just muting the other person while you’re talking (most phones and software applications—including Skype—do that, and it sucks).

As Christian nicely summarized, audio/video calls over the past few years have been a complex story. Unless you are close to GStreamer and Telepathy developers, it’s hard to see the big picture. Christian’s blog post is thus helpful, but I think it does not truly express how mindboggingly awesome this feature is, from a “What? Computers can do that? With Free Software?!” perspective.

A test call through XMPP/Jabber with Google Talk accounts. Notice that the echo-cancelled virtual device shows up in the GNOME volume control panel during the call. Yes, I cheated and used gnome-tweak-tool to change the control center’s colors to the dark variant.

Let me put it this way: I unplugged the headphones, called my laptop, put it into the garage, closed the door and went back to the previous room with the phone. I spoke, and I thought it was broken because the echo cancellation was working too well. I could not hear myself nor any audio artifacts. When I fetched someone else to go speak in front of the computer, it turned out that there was simply no echo whatsoever. Jaw on the floor. And that was with the laptop’s crappy 1-watt speakers; I then called across the globe to Bangalore, with my trusty USB microphone and 5.1 sound system, and it felt just like the other person was in the same room as me.

It works even if there’s ambient noise. The only way to confuse the echo canceller is to be in the same room with both the phone and the laptop. Not likely, unless you like talking to yourself.

Finally, no more fumbling around to pick up a call when your gear is not plugged in. Conference calls the way they were meant to be. Hands-free discussions while cooking or in a car. Holy smokes, we’re only missing holograms and flying cars… Folks, you know what to do.

Although I’m superhuman and can shoot down hundreds of bugs with my laser eyes and uncanny searching abilities, I need some help here. If we had a concerted SWAT team of cleaners/triagers, each closing a dozen bugs every day (focusing together on one specific project at a time), we would get the whole situation under control in no time. Start small but regularly: unless you’re feeling motivated in doing batches/sprints of 50-100 in a row, start by cleaning up a dozen of them per day (and then force yourself to stop). This is a great way to contribute to GNOME if you’re a power-user who doesn’t code.

Some general principles I would like to share in this blog post:

• Move fast and avoid staying in limbo. NEEDINFO everything you’re unsure about. In six months, with a special search query, close any remaining NEEDINFO that has not been clearly answered (if the GNOME bugsquad doesn’t do it for you for free). For example, here’s a search query showing all NEEDINFO bugs that haven’t changed in the last three months.
• Be polite but firm. If you know the project’s vision, show some courage and learn to say no or “patch or it won’t happen”. If you lack experience and have doubts, ask the devs for a “yes/no” decision on a given bug. You’ll learn a lot that way.
• Do regular cleanup sessions every few months or when undergoing a significant technological or ideological change. Know the “big projects” on the roadmap and seize opportunities for cleanups (ex: old untouched bugs, core engine changes, UI redesigns and focus changes, …).

These principles stem from my personal experience, from “lean” manufacturing and the theory of constraints, from the “Getting Things Done” methodology, and from interesting articles such as Havoc Pennington’s or Joel Spolsky’s. The 2nd half of Havoc’s “Free software UI” article is mandatory reading to understand GNOME’s development philosophy of the last decade. Joel’s “Software Inventory” article has some fascinating/provocating ideas when it comes to bug tracking (but really, that’s just lean manufacturing applied to software development):

“[...] the desire never to miss any bug report leads to bug bankrupcy, where you wake up one day and discover that there are 3000 open bugs in the database, some of which are so old they may not apply any more, some of which can never be reproduced, and most of which are not even worth fixing because they’re so tiny. When you look closely you realize that months or years of work has gone into preparing those bug reports, and you ask yourself, how could we have 3000 bugs in the database while our product is delightful and customers love it and use it every day?

[...] stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.”

This is what this blog post is all about. Reducing our excess inventory.

Towards that goal, here are some bug searching tips:

• Search for all bugs reported on [insert your deprecated technology here] (in Epiphany’s case, the Gecko/XULRunner backend). If they still affect the new backend, bump version numbers and change components as required. Otherwise, if they are not easily reproducible, kill them all.
• Search and verify all bugs older than 400 days, 800 days. Chances are they are fixed, obsolete, out of scope, duplicates, or crack (requesting features from the 80′s that 0.1% of users care about).
• Developers/maintainers: search for all unreviewed patches. Forward-port and merge yourself, or ask the reporter to do it and NEEDINFO/close in the meantime. The longer you let a patch sit there (even if it’s not 100% perfect), the harder it will be to manage and the more likely it is to be completely obsolete/wasted.

In the case of Epiphany, I added links in https://live.gnome.org/Epiphany/Development for sample search queries for the items above. You can adapt them for most projects.

The art of saying no

When faced with a bug report, you have three choices, especially when it comes to features:

• “Yes”. Only if it fits the project vision and you care enough about this feature to implement it yourself in the foreseeable future.
• “No for now, yes if you provide a patch”. Until then, close the bug report, or if you kinda care about the feature, confirm it, tag it “gnome-love” and possibly lower its priority.
• “No, out of scope. Sorry”. Be respectful and polite (you can’t implement everything out there due to insufficient manpower or because feature X would go against the project vision/intended UX; a canned message for that helps a lot). People will respect your decision more if they know your constraints and why you have to say no.

TL;DR: uncontrolled feature requests are vicious beasts that will eventually cloud your vision and suck your blood. Keep them at a safe distance.

Before you start flaming, keep in mind the context in which I’m saying this: long-term maintainability, a clearly defined scope, reasonable goals, a lean and agile approach, etc. I’m not saying that suggestions for enhancements/features are not valuable (they are, very much), but they need to be carefully and realistically evaluated.

Decisions need to be taken

Indecision is paralysis. Leaving a 7 years old bug report open because “nobody has made a decision” is not going to help developers attain a lean process. In bug 167592 for instance, I politely request the devs or design team to say a final yes or no, not a “maybe, I don’t know”. If we don’t decide now, we never will.

This approach may seem harsh to many (especially if you’ve never done long-term software maintenance and development), but it is the only sustainable way forward. Remember the goal: adherence to a clear vision, minimal “inventory” and achieving a lean/agile project flow.

Additional tips for bug triagers

• Retitle/rename bugs to be clearer, verbose and using common words. This makes them easier to find (preventing duplicates) and makes it easy to know what they are about at a glance.
• The “gnome-love” keyword to identify items that would be easily implemented by potential new contributors is a very important keyword.
• The “ui-review” keyword is your friend. We should start using it systematically whenever we’d like the GNOME design team to advise on a decision to be taken.
• Canned replies are very handy tools in your arsenal. Do take time to prepare some custom stock responses for your project’s particular needs, of course.
• If you’re really crazy about a particular project, you can subscribe to all of its bug mail (see the “About the -maint aliases” section on this page), after your big cleanup, to keep an eye on things in the future.

See the GNOME bugsquad page for more tips.

Are you looking for adventure? Join the bug squad!

Which projects to work on?

We can look at the top 15 gnome modules:

• GTK+, GStreamer and Evolution are of course huge scary beasts that we cannot concern ourselves with for the time being (unless some of you want to make some special triaging hackfest for them?).
  • Let’s applaud the efforts on Evolution, though: I remember it having 5000 open bug reports only a few years ago. It can be said that the situation is gradually getting under control there, though the recent de-involvement of SuSE is quite worrying.
• What remains? Core apps we use everyday: GNOME Shell, Rhythmbox (or Banshee, if you use that), Epiphany and Nautilus. In all cases, they are certainly full of old reports that are not reproducible anymore (or fixed), and in Epiphany and Nautilus’ cases, many reports that don’t fit their new vision anymore.
• However, this doesn’t give us a truly complete picture, because this report ignores feature requests. If you count the feature requests, for example, Empathy would probably show up here. It’s a good start though.

There is a big opportunity for cleanup here and we need a larger bug squad, made of users who know enough about the software they use (and the project vision) to help developers keep their sanity and direction. Talk to your friendly developers beforehand, but I’m pretty damn sure they will be delighted to have your help to bring back clarity.

Of course, this mission does not rest solely upon the shoulders of the bug squad. Developers are the best-positioned people to know when a bug is obsolete or not, and it is also your responsibility, as a software maintainer, to periodically go through “old unchanged bug reports” (on a lazy afternoon, once or twice a year, depending on your release cycle). This is what I do, for example, when a new Pitivi release comes out, and this is why the Pitivi bug tracker is a system that is kept in order, a system that I can trust and something I can actually refer to instead of something I would avoid.