Plop les bovins !!! Aujourd’hui je vous propose un post un peu particulier puisque je vais faire la traduction de l’excellent article de Aaron Seigo, célèbre développeur du projet KDE SC depuis près de 13 ans , chef de projet du projet Plasma Workspaces et un des initiateurs du projet Plasma Active.
Cet article est disponible dans son écriture original (dans la langue de Shakespeare) sur le Blog de Aaron Seigo. Ce que je vous propose ici est une traduction de ce dernier, je me permets également de donner mon avis sur certains points. Je tiens également à préciser que ce ne sera pas une traduction littérale du billet de Seigo, la traduction n’étant pas mon métier, je me réserve le droit de réarranger certaines phrases afin qu’elles soient plus faciles pour moi à retranscrire.
Nous sommes proches du Gel des fonctionnalités de la version 4.11, et cela m’a semblé être le bon moment pour partager quelques infos et décisions qui ont été prises. « Plasma Workspaces 4.11″ sera une version majeur pour deux raisons :
Ce sera la dernière des versions apportant de nouvelles fonctionnalités pour la série 4.x de Plasma Workspaces. La branche de développement de nouveautés va passer à Qt5 et KDE Framework 5 qui est basé sur Plasma Workspace 2.
Nous fournirons des corrections visant la stabilisation (correction de bugs, amélioration de la traduction, etc..) pour la version 4.11 de KDE Plasma Workspaces sur une période de deux ans.
Avant de donner plus de détails, laisser moi apporter quelques lumières :
Ceci n’affecte que le code actuel du dépôt kde-workspace. Les applications ne seront pas affectées, kdelibs et kderuntime poursuivront leurs développements comme il se fait actuellement (avec kdelibs qui possède son propre cycle). Je m’attends vraiment à ce qu’il y est une version 4.12 tout comme une version 4.13 des applications, le temps que cela prendra dépendra des équipes de développeurs et du cycle de sorties choisi.
Cela étant dit, expliquons plus en détails ces changements !
Support sur le long terme (Long Term Release)
L’un des points que je trouve des plus passionnant avec ce nouveau cap c’est que nos partenaires qui s’occupent de la diffusion et du packaging seront à même d’avoir des versions qui se focaliseront exclusivement sur la stabilisation du code et ce pour une période d’au moins deux ans. Il n’y aura aucune nouvelle fonctionnalité ajoutée après la sortie de la version 4.11.0 que ce soit au niveau du « Plasma Desktop » ou de l’interface « Netbook »; ainsi, le code pourra être ajusté à volonté pour le maintien et l’amélioration des fonctionnalités existantes. Cela ferait de « Plasma Desktop 4.11″ un excellent candidat pour les distributions à durée de vie très longue.
C’est une excellent occasion d’améliorer davantage le polissage général, vu que le temps disponible est plus long. Souvent entre deux sorties de versions, beaucoup de composants sont réécrits, et quelquefois cela résulte par une perte temporaire du « polissage » sur certaines parties. Or avec un cycle de sortie plus long, ces améliorations pourront s’accumuler naturellement au profit des utilisateurs.
Nous espérons que les améliorations en cours viendront répercuter la version initiale de « Plasma Workspaces 2″.
Ceci fut un des secrets du succès de KDE 3.5 (à l’époque où nous appelions encore l’ensemble « KDE » .. suite au prochain numéro ): Il eut pendant très longtemps des améliorations se focalisant exclusivement sur la stabilisation et le polissage. Nous travaillions sur la version 4.0 à cette époque, mais il nous a été démontré qu’avoir une version maintenue sur le long terme pouvait être une bonne chose. Nous avions même fourni à l’époque deux versions pour la branche 3.5.x après la 4.0; et avions annoncé notre intention de le faire lors de la sortie de la 4.0. Malheureusement, le public l’a tout bonnement ignorée, une des raisons pourrait être l’intérêt qu’a provoqué la sortie de la nouvelle version majeure.
Heureusement, avec cette annonce anticipée, et l’obtention de la version long terme bien en avance par rapport à « Plasma Workspace 2″, les distributions seront mieux préparées et seront à même de planifier plus efficacement la suite des événements.
Découpler l’ensemble des technologies (en quelque sorte)
Comme l’ensemble des projets KDE ont grandi tant en nombre qu’en portée, l’une des choses qui nous semblait évidente est que le maintien d’un seul cycle de développement ne pouvait plus convenir aussi bien à l’ensemble des projets. Les grosses bibliothèques bénéficiaient d’un cycle de développement long avec peu de changements tandis que les plus petits projets veulent des cycles rapides. Ainsi un planning de deux sorties par an, bien que convenant parfaitement au développement du Shell, constitue pour les applications une durée trop importante pour un développement confortable. Lorsque nous augmentons les dépendances entre les bibliothèques et les applications, chronométrer le tout correctement pour bénéficier des avantages ou des améliorations liés aux bibliothèques devient extrêmement difficile.
Ceci fut l’une des préoccupations dont nous avons tenu compte lors du repositionnement de l’image « KDE », quelques années auparavant. Nous nous sommes réappropriés le terme « KDE » pour la communauté de participants et nous avons donné des noms à chaque ensemble de projets. Avec « KDE Framework 5″ (la prochaine version majeure des bibliothèques principales de KDE) et Plasma Workspaces 2, les deux évoluant en parallèle, nous sommes à présent libres de définir pour chacune d’entre elles, un calendrier de développement correspondant au mieux à ses besoins. Nous n’aurons plus à faire des compromis dans un sens ou dans l’autre pour trouver une date de sortie qui convienne aux deux. Cela veut également dire que les développeurs d’applications n’auront pas non plus à guetter les nouveautés de « Plasma Workspaces 2″. En effet, ils auront à disposition l’excellente version 4.11.x pour leurs développements et seront en mesure de migrer vers le « Framework 5″ de manière indépendante par rapport à « Plasma Workspaces 2″.
Je m’attends à ce que nous continuons les sorties coordonnées pour la partie « KDE Software », et j’ai l’espoir que davantage d’applications sortirons de nouvelles versions ces temps-ci maintenant que nous sommes passés au sens strict de l’idée qu’on peut se faire du terme « Software Compilation ». Cependant, les cycles développement ne seront pas les mêmes et certains projets se mettrons à jour plus souvent que quelques fois par an. Il y a en tous cas beaucoup de discussions et d’organisation à faire avant que tout soit parfaitement implémenté et fonctionnel. Il ne s’agit là que du premier pas de l’équipe Plasma.
Cela a déjà pris plusieurs années pour arriver à ce stade, notamment parce qu’il a fallu attendre le bon moment pour entamer les démarches de cette planification à grande échelle, mais c’est très agréable de sentir que l’on touche au but.
Raccourcir l’attente pour la sortie de Plasma Workspaces 2
Vu à tout ce qui a été dit plus haut, nous serons à même de concentrer nos effort deux fois plus sur Plasma Workspaces 2. Nous serons également en mesure de proposer des nouvelles versions quand elles seront prêtes, indépendamment de Framework 5. Et il n’est pas du domaine de l’impossible de voir par exemple , une version initiale de Plasma 2 au-dessus d’une version « preview » de Framework 5.
En restant concentrés sur nos objectifs et en maintenant un calendrier raisonnable pour chaque composant, nous serons à même de fournir Plasma Workspace 2 en temps et e heure (mais pas avant). Cela nous permet également d’élargir la portée d’un certain nombre de modules « orphelins » tels que NetworkManager ou bluedevil.
Ces composants sont actuellement développés dans des dépôts tiers qui se trouvent en dehors du cycle de développement de KDE Software Compilation. Cela serait plus cohérent pour ces projets puisqu’ils pourront sortir plus vite et plus facilement. Malheureusement, d’un autre côté cela rendrait la coordination et l’intégration plus difficile.
Avec l’approche de Plasma Workspaces 2 et cycle de développement propre, nous cherchons à regrouper tous ces projets ensembles. Le plasmoid « Networking » par exemple, ne devrait pas être un module développé en dehors du cycle principal de l’environnement, mais devrait être au contraire intégrée dans son intégralité à ce dernier. Donc au lieu de développer un Shell et d’attendre que toutes les pièces du puzzle viennent s’ajouter, nous allons procéder comme auparavant et fournir une expérience utilisateur complète et cohérente.
Comment en est-on arrivé là ?
Nous avons tout d’abord discuté de ces idées avec les développeurs du Plasma Desktop. Nous avons ensuite élargi cette discussion à l’ensemble des développeurs de la communauté Plasma et enfin, nous avons encore élargi notre audience en discutant avec la communauté présente lors du meeting Tokamak 6. Nous avons également communiqué avec la communauté KDE , dans un premier temps en nous approchant de la « release team » afin de nous assurer que la concrétisation de nos idée était réalisable. Puis, dans un second temps, nous avons posté une annonce dans les listes de diffusion kde-core-devel et des packagers en apportant encore plus de détails sur nos intentions. Ces discussions ayant donc fait leur petit bonhomme de chemin, je prends à présent le temps de les partager avec vous. :)
Le plan effectué a été fait par consensus (ce qui est différent d’une décision faite à l’unanimité) et le résultat a pris pas mal de temps. Néanmoins, nous avons eu beaucoup de retours et d’inquiétudes ce qui a permis d’améliorer le plan initialement formulé et ce sur de nombreux points. Il est encore un peu tôt , mais nous pouvons encore l’adapter pour faire un pas de plus vers son implémentation.
Conclusion
L’article de Aaron Seigo s’arrête donc sur cette note positive, je rajouterai pour conclure qu’il y a beaucoup de bonnes choses là-dedans (selon moi). On sent à la lecture du poste original, que les résolutions prises ont été murement réfléchies. Et malgré la difficulté de prendre de telles décisions dans un projet aussi immense que celui de KDE SC, les équipes ont su se rassembler et aller de l’avant. Et cette volonté de contenter aussi bien les utilisateurs que de préserver le bien être des développeurs prouve encore toute la considération des responsables du projet au bon fonctionnement de l’ensemble.
Le fait de tenir informer les utilisateurs permet de maintenir un contact permanent avec ces derniers. Selon moi, cela fait également partie de l’expérience utilisateur que l’on peut avoir d’un environnement.
Enfin, je terminerai (il serait temps :P) en disant que le rythme de développement qui consiste à sortir de nouvelles versions uniquement quand ces dernières sont prêtes me parait une solution cohérente. J’appréciais déjà cette philosophie au sein d’autres projets comme Xfce et la voir adaptée sur mon environnement de bureau préféré me fait très plaisir.
Moo !!!
Original post of Noireaude.Votez pour ce billet sur Planet Libre.
Plop les bovins, la première distribution utilisant Wayland et son compositeur Weston vient de sortir. C´est le développeur « Nerdopolis » qui a créé cet iso nommée RebeccaBlackOS, grâce à laquelle nous pouvons désormais découvrir ce qu´il se cache dernière le nom Wayland, en lançant des applications dont les fenêtres sont générées à l’aide cette technologie. Mais ce n´est pas tout, vous pourrez aussi lancer des logiciels qui utilisent X-Wayland, la solution de transition vers Wayland et le Qt-Demo-Browser basé sur Qt5. Le protocole de serveur d´affichage Wayland dont le développement a débuté en 2008, est destiné à remplacer l´actuel serveur d´affichage X.Org (X11) dans tous les systèmes d´exploitation basés sur Unix. Enfin tous ou presque, car Canonical (Ubuntu) a choisi de développer son propre display-manager, dont le nom de projet est Mir.
