UDS-R Jour 2

1. Matinée

Cette 2e matinée a été plus orientée « Desktop ». Cela a commencé par une session sur Upstart et son extension à la session utilisateur. Pour faire simple, il s’agit d’apprendre à Upstart (le gestionnaire de processus d’Ubuntu, remplaçant Init) à faire plein de choses intelligentes, comme démarrer des services seulement quand on en a besoin (bluetooth quand un appareil est connecté, update-manager quand des mises à jour sont disponibles …). L’intérêt est de supprimer les programmes lancés en arrière plan qui effectuent ce monitoring (update-notifier par exemple), qui prennent de la mémoire pour rien. C’est une bonne nouvelle, que je nuancerais par le fait que cette idée est dans l’air depuis au moins 3 ou 4 versions (remplacement de update-notifier), donc à voir … Plus d’infos sur http://summit.ubuntu.com/uds-r/meeting/21391/foundations-r-upstart-user-session-enhancements/

Ensuite, il y a une session sur la connectivité (http://summit.ubuntu.com/uds-r/meeting/21360/desktop-r-connectivity-checking/), avec notamment la gestion des portails captifs (Wifi qui semble non sécurisé, et qui nécessite une authentification sur une page web). On a aussi parler du remplacement de language-selector par l’utilitaire de Gnome pour gérer la prise en charge des langues. Il semble que pour ce cycle, cela va se faire. Heureusement, language-selector ne devrait pas disparaître, car les flavors non-GNOME et non-KDE s’en servent encore pour gérer cette problématique. Plus d’infos sur http://summit.ubuntu.com/uds-r/meeting/21529/desktop-q-deprecate-language-selector/

Après une autre session sur l’utilisation de l’iso-tracker pour faciliter l’organisation des sorties (http://summit.ubuntu.com/uds-r/meeting/21353/foundations-r-release-manifest-streamlining/), ce fut une session sur les plans de Xubuntu pour la version 13.04. Pas de migration prévue sur xfce 4.12 (sauf cas particulier), la gestion de l’affichage devrait toutefois’être améliorée. L’intégration de MenuLibre, pour remplacer Alacarte sera également testé, en collaboration avec l’équipe Lubuntu qui est toujours à la recherche d’un éditeur de menu. Plus d’infos sur http://summit.ubuntu.com/uds-r/meeting/21410/community-r-xubuntu-planning/

2. Plénières

Les plénières du jour étaient consacrées à Ubuntu en entreprises, avec un point sur le déploiement d’Ubuntu dans les entreprises et chez les manufacturiers informatiques, et une démo sur la connexion à distance directement par l’écran d’accueil (lightdm). Le constat est plutôt positif, les constructeurs certifient de plus en plus de machines, et les déploiements en entreprise commencent à être significatifs. Avec l’arrivée de Steam et autres éditeurs de jeux, la présentation laisse penser qu’Ubuntu n’est pas loin d’atteindre la taille critique pour peser sur les constructeurs pour qu’ils rendent leurs matériels compatibles avec Ubuntu. Il faudra voir dans le futur …

La deuxième présentation a été faites par HP, pour présenter leur projet de réduction de la consommation électrique de leurs serveurs.

3. Après-midi

L’après midi a aussi été orienté « Desktop », mais un peu plus polémique. Cela a commencé par la session habituelle sur la version de GNOME qui sera utilisée pour la 13.04. Il a été proposé, non pas de suivre le développement de GNOME, en incluant la dernière version (3.7/3.8), mais de rester sur la version actuelle de la 12.10 (3.6). A part GLib, dconf, et g-i, c’est cette politique de stabilité qui a été choisie. Même Gtk risque ne pas être mis à jour. C’est un changement important par rapport aux autres cycles, car jamais (si ma mémoire est bonne), une telle politique de gel n’a été décidé (hors LTS, et hors les 1e versions de GNOME 3). Cela démontre à mon avis plusieurs éléments :

* La relation Ubuntu – GNOME n’est pas au mieux. La remontée des problèmes ne passe pas bien, car si c’était le cas, les développeurs Ubuntu ne devraient pas avoir peur d’une version de développement.

* Les composants d’Ubuntu sont de moins en moins basés sur GNOME. En effet, l’un des arguments de cette décision est le temps passé à adapter le code spécifique d’Ubuntu aux changements de GNOME. S’il y avait peu de spécifique, le problème se poserait moins.

* Les versions de GNOME ne sont plus aussi fiables que lors de la série 2.X. A l’époque, je me souviens que faire une mise à jour entre 2 versions était très sûr. Tout le planning d’Ubuntu était (et est toujours) basé sur le planning de GNOME pour cette raison : 1 mois de décalage entre la sortie de GNOME et la sortie d’Ubuntu, c’était suffisant pour stabiliser et adapter la version stable de GNOME. Ce n’est clairement plus le cas.

C’est pour moi un changement majeur. A l’origine, le but d’Ubuntu était (grossièrement), de stabiliser une Debian Sid, avec la dernier version GNOME, et les dernières technologies libres. Quand on voit les discussions qu’il y a eu sur le passage à Debian testing (seulement pour les LTS, mais on a failli le faire pour les autres versions), et maintenant la version de GNOME, je ne peux m’empêcher de penser que les temps changent A noter que cette décision a un impact direct sur la nouvelle flavor Ubuntu-Gnome. Je les vois mal utiliser une « vieille » version de GNOME dans leur distribution … Plus d’infos sur http://summit.ubuntu.com/uds-r/meeting/21388/desktop-r-gnome-plans-review/

La session suivante a été dans le même style, mais parlait spécifiquement de Nautilus (le gestionnaire de fichiers). La version 3.6 a été très mal accueillit par les développeurs Ubuntu, et le but de cet session était s’aplanir les problèmes et trouver la meilleur façon de s’en sortir. Pas vraiment de solution au final, même si la version 3.8 pourrait être meilleur. Affaire à suivre. Mais, il semble que les changements d’interface qu’à subit Nautilus (et qui posent problèmes) pourraient aussi arriver sur d’autres composants de GNOME. On a pas fini d’en parler … Plus d’infos sur http://summit.ubuntu.com/uds-r/meeting/21371/desktop-r-default-file-manager/

Enfin, la dernière session était sur la nouvelle façon de tester les ISOs sans passer pas les Alphas. Cela consiste à effectuer les tests toutes les 2 semaines, sur une semaine glissante. Plus d’infos sur http://summit.ubuntu.com/uds-r/meeting/21080/qa-r-testing-cadence/