GNOME envisage de migrer vers GitLab

Logo GitLab

Dans un message envoyé sur la liste de diffusion dédiée au développement de GNOME, plusieurs développeurs proposent d’abandonner Bugzilla et Cgit au profit de GitLab, qu’ils jugent bien plus moderne et qui faciliterait la vie de tout le monde. Phabricator, la forge adoptée par KDE, fut également envisagée, mais la gestion de code et le workflow proposés par GitLab semblent plus correspondre aux besoins du projet GNOME.

Un wiki a été mis en place pour aborder la migration. On peut y lire les différents problèmes rencontrés par les solutions actuelles (aucune interface graphique pour les tâches courantes concernant la gestion du code, revue de code médiocre, mauvaise intégration, inutilement compliqué, absence de certaines fonctionnalités…), ainsi qu’un comparatif entre GitLab et Phabricator. Une instance de test de GitLab a également été mise en place pour ceux qui souhaiteraient l’essayer.

Ci-dessous, une traduction du message d’Allan Day, que j’espère plutôt juste, n’étant absolument pas bilingue /o\

Chère communauté,

Avec les années qui passent, nombre d’entre nous sommes de plus en plus frustrés par l’état de notre infrastructure de développement. En particulier Bugzilla. Pratiquement toutes les personnes avec qui nous en avons discuté ne l’aiment pas, et il n’est pas difficile de comprendre pourquoi : il contient de nombreux problèmes d’utilisabilité, la revue de code est un enfer et il est à des années lumière de ce que proposent les plates-formes de développement plus modernes.

Par le passé, il n’y avait pas beaucoup d’alternatives, mais nous avons désormais la chance de pouvoir choisir parmi différentes solutions viables, tout en ayant les ressources nécessaires au niveau de l’administration système pour la mise en place et la maintenance de l’une d’entre elles.

Au cours des derniers mois, nous nous sommes réunis pour examiner les différents choix possibles pour l’infrastructure de développement de GNOME. Nous y avons consacré beaucoup de temps, parce que nous voulons que la communauté ait confiance en nos conclusions. Si le sujet vous intéresse, vous pouvez consulter nos recherches sur le wiki.

Les résultats de ce processus d’évaluation nous amènent à recommander au projet GNOME de mettre en place sa propre instance de GitLab, en remplacement de Bugzilla et Cgit.

Nous sommes convaincus que GitLab est un bon choix pour GNOME et nous sommes impatients que GNOME puisse le proposer pour moderniser notre expérience de développement. Il nous fournira des outils beaucoup plus efficaces, facilitera l’intégration des nouveaux arrivants et améliorera notre façon de travailler. Nous sommes prêts à travailler sur la migration.

N’oubliez pas qu’il s’agit d’une recommandation ! Nous ne prétendons pas avoir toutes les connaissances et nous aimerions pouvoir en discuter. Par contre, nous demandons à la communauté d’aborder cette proposition avec un esprit ouvert : lisez le wiki et évitez les suppositions concernant GitLab si vous ne vous êtes pas familiarisé avec lui.

Allan Day

Étant donné que les principaux développeurs semblent particulièrement enthousiastes par un tel changement, il est évident que la migration se fera bel et bien. Par contre, aucune date n’a encore été annoncée, ni le temps nécessaire pour une telle migration, particulièrement conséquente au vu du nombre de projets hébergés par le projet GNOME.

Mais une chose est sûre. Tout ce qui facilite la vie des contributeurs et l’arrivée de nouveaux participants est à encourager. Il en va de la vitalité et de l’avenir du projet.

Et il devint bien plus simple de contribuer à GNOME…

Jusqu’à aujourd’hui, si l’on souhaitait contribuer à une application GNOME, il fallait impérativement disposer d’une distribution récente, télécharger de nombreuses bibliothèques et autres modules, affronter l’enfer des dépendances… sans oublier les inévitables problèmes aléatoires.

Carlos Soriano, le mainteneur de Fichiers, explique qu’il fallait autrefois six bonnes heures pour tout mettre en place avant d’espérer pouvoir enfin contribuer au gestionnaire de fichiers. Maintenant, en seulement cinq petites minutes, tout est prêt.

Il n’y a plus besoin de se soucier de la distribution utilisée, des versions nécessaires ou de devoir gérer les dépendances. Mieux encore, la procédure est totalement reproductible, ce qui signifie que si tout fonctionne bien chez les développeurs du projet qui vous intéresse, ça fonctionnera obligatoirement chez vous également. Cerise sur le gâteau, tout s’effectue au sein d’un environnement de développement moderne. Vous n’aurez donc plus besoin de taper d’obscures lignes de commande dans un terminal.

On doit ce petit miracle à Alex Larsson, le créateur de Flatpak, ainsi qu’à Christian Hergert, le développeur de Builder. Sans oublier Bastian Ilsø pour la création du guide des nouveaux arrivants.

Clonage d’un projet dans Builder 3.22

Une fois Builder lancé, il vous suffit de cliquer sur le bouton Cloner puis d’indiquer le dépôt git du projet qui vous intéresse. L’application se chargeant de télécharger tout le nécessaire pour pouvoir vous offrir un environnement de travail totalement fonctionnel. Vous n’aurez ensuite plus qu’à effectuer vos contributions ^_^

Mais avant de vous lancer dans l’aventure, point crucial, il vous faut obligatoirement Flatpak 0.9.1 ou supérieur.

Pour plus d’informations, vous pouvez consulter le billet de blog de Carlos Soriano, et bien évidemment, le guide des nouveaux arrivants.

GTK+ 4.0 ne sera pas GTK+ 4

GTK+ Hackfest 2016 (© Matthias Clasen)

Le GTK+ Hackfest 2016 se déroule en ce moment même à Toronto. Plus d’une quinzaine de développeurs s’y sont retrouvés pour trois jours de développement et de discussions, décidant ainsi du futur de cette bibliothèque utilisée pour concevoir les interfaces graphiques des applications GNOME et d’un certain nombre d’autres projets majeurs.

L’une des discussions ayant fait le plus de bruit concerne le versionnage des prochaines versions majeures (GTK+ 4, 5, 6…).

Depuis la sortie de GTK+ 3.0 en février 2011, les nouvelles versions mineures se sont succédé ces dernières années, apportant à chaque fois leur lot de nouvelles fonctionnalités, mais également de problèmes, cassant régulièrement l’API ou les thèmes utilisateurs. À tel point que ce manque de compatibilité ascendante est désormais l’une des critiques les plus courantes, et que différents projets ont préféré abandonner GTK+ au profit de Qt, ou de retarder leur migration de GTK+ 2 vers la version 3.

Pour rappel, GTK+ 1 est sorti en 1998, GTK+ 2 en 2002 et GTK+ 3 en 2011. Des écarts toujours plus grands, qui obligent à apporter régulièrement de nouvelles fonctionnalités pour pouvoir coller aux nouvelles technologies ou couvrir de nouveaux besoins.

L’une des solutions envisagées, serait de sortir plus régulièrement de nouvelles versions majeures, considérées comme stables, qui ne recevraient plus que des correctifs améliorant la stabilité ou la sécurité (pour de plus amples informations, je vous conseil la lecture des deux billets de blog d’Allison Lortie, Gtk 4.0 is not Gtk 4 et Gtk 5.0 is not Gtk 5).

Après la sortie de GTK+ 4, qui ne devrait probablement pas avoir lieue avant 2018, une nouvelle version majeure sortirait approximativement tous les deux ans. Et entre chaque nouvelle version majeure, nous continuerions comme aujourd’hui de bénéficier de nouvelles versions mineures tous les six mois, qui apporteraient leur lot de nouveautés.

Mais c’est là que ça se gâte. Pour le moment, on semble se diriger vers un GTK+ 4 qui ne correspondrait pas à GTK+ 4.0. Et il en irait de même pour GTK+ 5 ou 6. En gros, durant les dix-huit premiers mois (ce qui correspond à trois versions mineures), les développeurs seraient libres d’ajouter de nouvelles fonctionnalités et de casser l’API autant qu’ils le souhaitent. Une fois le code stabilisé, il sera alors décidé que GTK+ 4.6 ou 4.8 pourra devenir le nouveau GTK+ 4.

GTK+ Hackfest 2016 (© Matthias Clasen)

À ce moment de l’article, vous ne pouvez vous empêcher de trouver ça idiot et de vous demander pourquoi ils ne travailleraient pas plutôt sur une branche de développement qui, une fois stabilisée, donnerait GTK+ 4.0, première version stable de cette nouvelle branche ?

De l’avis des développeurs, il semble y avoir deux publics, qui ont chacun des besoins différents. D’un côté des projets comme GNOME, qui souhaitent pouvoir bénéficier rapidement des dernières nouveautés sans avoir besoin d’attendre deux ans. Projets qui, de par leur taille, auront toujours la main d’œuvre nécessaire pour adapter les différentes applications aux éventuelles nouveautés ou autres cassures d’API. Et de l’autre, les développeurs d’applications tierces, qui préféreront plutôt se baser sur une version stable qui ne bougera plus, et ne nécessitera donc plus une maintenance incessante et régulière.

Maintenant, il faut savoir que les discussions ont toujours lieues et qu’aucune décision ne sera prise avant le prochain GUADEC, qui se tiendra cette année du 12 au 14 août en Allemagne. Il est donc possible que le versionnage change encore d’ici là. Mais une chose est sûre, de l’avis même des développeurs, des versions stables plus régulières devraient faciliter et accélérer le développement, ce qui devrait nous apporter plein de bonnes choses dans les années à venir.

Une inconnue demeure néanmoins. Combien de branches seront maintenues en parallèle ? Surtout quand on sait que GTK+ 2, qui en est actuellement à la version 2.24.30, est toujours maintenu, près de quinze ans après sa première apparition.

Annonce du Libre Application Summit

La fondation GNOME vient d’annoncer la première édition de la conférence Libre Application Summit, qui se tiendra du 19 au 23 septembre à Portland, dans l’Oregon. Cette dernière devant permettre d’accroître l’écosystème d’applications GNU/Linux en améliorant la collaboration entre le noyau Linux et les principales distributions, ainsi qu’en attirant les développeurs d’applications, aussi bien chez les indépendants que chez les gros éditeurs.

Un panel varié de participants y est attendu, que ce soit des développeurs du noyau, de distributions, des fabricants de matériel, des développeurs de pilotes de périphériques, d’applications ou de jeux vidéos (aussi bien libres que propriétaires), dans le but de pouvoir échanger plus facilement, voir quelles sont les problématiques respectives rencontrées et ce qui pourrait être fait pour y remédier (meilleure documentation, création de meilleurs outils de développement, amélioration de l’expérience, aussi bien pour les utilisateurs que pour les développeurs…).

De nombreuses conférences auront lieues, traitant aussi bien de l’écosystème (questions commerciales, juridiques, sociales, communautaires), que de la plateforme (matériel, pilotes, outils), de la distribution (collaboration entre les distributions, l’assurance qualité, l’intégration continue), ou du développement (les toolkits, X / Wayland, la sécurité, les SDK, les différents outils).

Je pense sincèrement que ce type de rencontre manquait cruellement, et il n’y plus qu’à espérer que cette première édition soit un succès, histoire de pouvoir aider à rendre notre plateforme bien plus attractive pour les développeurs, et par ricochet, les utilisateurs.

Nouveau composant GTK+ pour l’affichage des images

Dans le but d’éviter la duplication de code et ainsi faciliter le développement et la maintenance des différentes applications qui nécessitent de pouvoir afficher une image en taille réelle (le Visionneur d’images, Photos, un client Twitter ou de messagerie…), Timm Bäder s’est attelé à développer un nouveau composant GTK+, GtkImageView.

Bien que toujours en cours de développement, ce dernier devrait, à terme, offrir des possibilités de mise à l’échelle, rotation, chargement asynchrone, prise en charge des gestes tactiles (pour la mise à l’échelle et la rotation), tout en permettant de définir différents niveaux de zoom.

Interview de Cédric Bellegarde, développeur de Lollypop

Régulièrement, lors des sorties de nouvelles versions de GNOME ou KDE (voir de tout autre environnement de bureau), des utilisateurs des différentes communautés se lancent dans des flamewars pour mettre en avant leurs propres choix et dénigrer ceux de l’adversaire. Pour les personnes ne s’intéressant pas particulièrement à la technique, il est parfois difficile de faire la part du vrai, et j’ai donc trouvé intéressant d’interroger Cédric à ce sujet, qui connaît bien ces deux environnements pour avoir développé sur l’un et l’autre.

Et nous en profiterons bien évidemment pour en savoir plus sur l’avenir de Lollypop, dont la dernière version de cet excellent lecteur de musique vient tout juste de sortir.

Peux-tu te présenter brièvement, ainsi que ton parcours ?

Alors, Cédric Bellegarde, je vis dans l’Anjou, j’ai une formation niveau DUT très orientée développement. Malgré cela, ma seule expérience professionnelle dans ce domaine est mon stage de fin d’études chez Aliacom sur le logiciel OBM (chez Linagora aujourd’hui). Je me suis ensuite orienté dans l’administration système et réseau dans le milieu universitaire.

Dans le domaine du libre, j’ai dès 2003/2004 rencontré la communauté Mandrake française en contribuant à quelques paquets pour la distribution. Par la suite, de 2006 à 2007, je contribue activement au projet Compiz et Compiz-Fusion sur la gestion des fenêtres en particulier. En 2007, première expérience avec Python+GTK avec un client MPD (sources, capture d’écran).

Fin 2008, je migre sous KDE4,  je contribue à différents projets : rekonq, oxygen-gtk, kdepim… En 2013, un projet attire mon attention, se baser sur le travail de Canonical pour déporter la barre de menu de manière native sous KDE. Je me lance donc dans kded-appmenu et contribue directement à Kwin.

Par la suite, je me rends compte que j’ai de plus en plus de mal avec le bureau de KDE et certaines applications qui sont bien trop complexes, mais GNOME 3 ne me donne pas du tout satisfaction.

Il faudra attendre la sortie de GNOME 3.12 pour que je sois conquis et commence à imaginer le lecteur  de musique de mes rêves.

Au vu du grand nombre de lecteurs audio sous Linux, qu’est-ce qui t’a poussé à te lancer dans le développement d’un tout nouveau projet ?

J’ai d’abord utilisé Musique avec plus ou moins de succès, mais il était très lent, trop lent…  Après avoir étudié le code de ce dernier et trouvé le goulot d’étranglement (tracker), j’ai migré temporairement sous Clementine et commencé à développer Lollypop en reprenant les concepts de base de GNOME Musique.

Concevoir une bonne interface, agréable à utiliser et bien pensée, est une tâche difficile. Quelles difficultés as-tu rencontré, et est-ce que les GNOME Human Interface Guidelines t’ont été utiles, durant ce processus ?

C’est en parti ces règles qui m’ont fait passer sous GNOME. J’aime beaucoup le « look & feel » des applications GNOME et j’ai construit Lollypop autour de ces principes, qui sont assez proche de ce que fait Apple sur certains points, mais avec une contrainte en plus : pas de menu global à l’application. Je trouve aussi que les nouveautés de GTK+ sont vraiment les bienvenues après de nombreuses années de stagnation et permettent d’explorer de nouvelles façons de concevoir une application.

Quelle distribution utilises-tu, et quels sont tes outils de développement ?

Je développe principalement sous Fedora et Debian/Ubuntu. Comme outils, simplement Gedit/Devhelp et Glade.

As-tu suivi le développement de Builder, l’IDE pensé pour faciliter le développement d’applications GNOME ? Penses-tu que ça aille dans le bon sens, et envisages-tu de l’utiliser, à terme ?

Oui, cela va dans le bon sens, mais je trouve dommage que cette étape arrive avant la mise à niveau de Glade qui ne gère pas du tout les nouveautés de GTK+.

J’ai lu sur LinuxFR que tu étais auparavant sous KDE. En tant que développeur, le changement de technologies fut-il aisé ?

Oui, les principes sont les mêmes… Python/GTK+ ou C++/Qt, c’est relativement la même chose, même si Python permet vraiment de développer plus rapidement que C++. Par contre, j’ai trouvé plus de réponses à mes questions sur le web lors du développement de Lollypop que pour mon travail sur KDE…

On reproche souvent à GNOME et ses différentes technologies (Gtk+, GStreamer…), d’être moins bien documentés que certains « concurrents ». La situation est-elle réellement si mauvaise ?

La documentation de GTK+ est toujours moins bonne que celle de Qt, mais les moyens ne sont pas les mêmes. De plus, la documentation des bindings est bien meilleure côté GTK+. C’est surtout la documentation de KDE qui n’est pas au niveau ni de Qt ni de GTK+/GNOME.

Un autre reproche qui revient régulièrement, est de devoir faire de l’orienté objet avec du C. GNOME offrant la possibilité d’utiliser le langage de son choix, en tant que développeur Python d’une application utilisateur, en as-tu souffert ? Est-ce que ça t’a contraint à adapter ta façon de développer ?

Effectivement, je n’aime pas du tout le couple C/Gobject mais cela permet à GNOME d’offrir des bindings à jour pour de nombreux langages via Gobject Introspection, ce qui n’est pas le cas sous KDE. De plus, entre Vala et Python, je pense que personne n’a besoin de faire de l’orienté objet avec du C pour faire une application GNOME.

De toutes les possibilités offertes par la plate-forme GNOME, qu’est-ce qui t’a le plus plu ?

GtkHeaderBar (la barre d’en-tête, ndr) sans hésiter. Une grande avancée. Depuis le temps que je voulais voir une nouvelle façon de faire des applications sous GNU/Linux. C’est la suite logique de mon travail sur KDE. Je ne supporte pas les barres de menus. GNOME a réussi à les reléguer au second rang. Côté KDE, ils veulent faire à terme communiquer le gestionnaire de fenêtres avec l’application, mais du point de vu du développeur cela n’offrira jamais la flexibilité de GtkHeaderBar.

Quels conseils donnerais-tu à un développeur GNOME débutant, qui souhaiterait se lancer dans le développement d’une nouvelle application ?

Commencer par contribuer à un outil existant afin de mieux se familiariser avec l’environnement. Je n’ai pas un énorme niveau en programmation et j’ai beaucoup appris des mes contributions à Compiz et KDE. Il ne faut pas croire qu’il faut être ingénieur pour faire ce boulot. On est sur du haut niveau, je n’aurai pas la prétention de savoir coder Lollypop en C sans GStreamer :)

J’ai cru comprendre que tu t’occupais toi-même de la création de paquets pour Arch, Fedora, Ubuntu… N’est-ce pas trop pénible, quand on sort régulièrement de nouvelles versions ? Pourquoi ne pas avoir délégué cette tâche ?

Une fois Lollypop intégré dans les distributions, je ne ferais plus les paquets… Sauf si j’ai toujours le temps de fournir la dernière version.

D’avoir aujourd’hui autant de distributions et d’environnements de bureau (GNOME, Pantheon, Unity…), rend-il les tests qualité plus nombreux et difficiles ?

Oui pour Unity, car Canonical rejette les paradigmes de GNOME (la barre d’en-tête en particulier). Pour le reste, cela ne change rien, ils sont tous compatibles avec GNOME.

GNOME et Red Hat ont commencé à travailler sur le support des applications sandboxées. L’un des avantages étant de pouvoir permettre à des développeurs tiers de fournir un paquet unique qui tournerait partout, sans avoir à se soucier de la distribution ou de la version de GNOME utilisées par l’utilisateur. En tant que développeur et responsable de paquets, qu’en penses-tu ?

Que c’est une très bonne chose, car il est effectivement chiant de faire des paquets pour toutes les distributions. Reste à voir si la mayonnaise prend, mais d’un point de vue technique ça me semble bien pensé.

Trop d’options et de fonctionnalités rendent souvent les interfaces plus chargées et les applications plus difficiles à prendre en main. Penses-tu être proche de cette limite, ou as-tu encore de nombreuses idées à implémenter ?

Avec la 0.9.30 qui sort demain (à l’heure où je réponds à cette question), j’ai fais le tour, c’est la dernière version avec de nouvelles fonctionnalités avant la 1.0. Après, je rajouterai des fonctions si les propositions me semblent pertinentes.

Un grand merci à Cédric d’avoir bien voulu prendre le temps de répondre à mes quelques questions ;)