Il n'y a pas forcément de ligne directrice. Du point de vue de la qualité du code, un processus de revue existe depuis très longtemps, au départ c'était fait via une mailing list et après l'envoi de commits (c'était la façon la plus simple de procéder avec SVN), aujourd'hui, cela passe par Gerrit avec une revue avant commit. L'inconvénient est que parfois c'est un peu trop exigeant et c'est difficile d'intégrer un changement qui n'est pas parfait, cela peut décourager certains contributeurs.
Du côté de l'interface graphique, il y a un document "Haiku interface guidelines", mais c'est vrai qu'il y a une attention aux détails. C'est peut-être plus facile de se consacrer à ça quand le gros de l'interface a très peu changé depuis 25 ans, que pour d'autres projets qui sont un peu dans un changement continu de technologie ou de thèmes ou d'objectifs?
La roadmap avance doucement. Pour s'en rendre compte on peut regarder année par année:
Il faut noter que les tickets résolus sont déplacés vers la beta "en cours" au moment de la résolution. Chaque version beta reçoit plusieurs centaines de corrections, mais de nouveaux problèmes sont également découverts. Donc le nombre de tickets dans l'objectif "R1" baisse beaucoup plus doucement (mais ça baisse quand même). Si on garde le même rythme de -120 tickets tous les 4 ans (environ 30 par ans), on devrait voir la version R1 d'ici environ 18 ans.
Il s'agit d'un rapport trimestriel qui liste les avancées de ces 3 derniers mois uniquement. Pour les 3 mois précédents il faut regarder le rapport précédent, et ainsi de suite. L'équipe est toujours assez réduite (un développeur salarié, une grosse poignée de contributeurs sur leur temps libre, et quelques personnes qui participent de façon plus occasionelle). Cette année, on a entre 7 et 22 contributeurs chaque mois avec un total de 44 personnes différentes sur l'année (la dernière année où il y a eu aussi peu de monde, c'était en 2010, et les chiffres pour 2010 et avant sont faussés parce que on utilisait encore SVN qui ne préservait pas l'auteur pour les contributions externes). On est donc plutôt en effectif réduit par rapport à d'habitude, avec un seul contributeur qui réalise a lui tout seul plus de la moitié des commits (c'était le cas l'an dernier pour la première fois, jusque là, les choses étaient beaucoup plus réparties, mais il n'y avait pas un contributeur salarié à plein temps). Avec environ 1000 à 1500 commits par an, on est loin du record de 2009 ou on avait dépassé 5500 commits. Cependant, les changements de mode de revue du code font que les changements ont tendance à apparaître sous forme d'un seul commit bien testé et finalisé, au lieu de multiples petits changements et correctifs.
On peut aussi regarder du côté de Haikuports, les courbes se sont croisées avec l'introduction en 2012 du gestionnaire de paquets, et on voit beaucoup d'activité sur le portage et le développement de logiciels, plutôt que sur le système lui-même.
[^] # Re: plein de questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 9.
Il n'y a pas forcément de ligne directrice. Du point de vue de la qualité du code, un processus de revue existe depuis très longtemps, au départ c'était fait via une mailing list et après l'envoi de commits (c'était la façon la plus simple de procéder avec SVN), aujourd'hui, cela passe par Gerrit avec une revue avant commit. L'inconvénient est que parfois c'est un peu trop exigeant et c'est difficile d'intégrer un changement qui n'est pas parfait, cela peut décourager certains contributeurs.
Du côté de l'interface graphique, il y a un document "Haiku interface guidelines", mais c'est vrai qu'il y a une attention aux détails. C'est peut-être plus facile de se consacrer à ça quand le gros de l'interface a très peu changé depuis 25 ans, que pour d'autres projets qui sont un peu dans un changement continu de technologie ou de thèmes ou d'objectifs?
La roadmap avance doucement. Pour s'en rendre compte on peut regarder année par année:
Il faut noter que les tickets résolus sont déplacés vers la beta "en cours" au moment de la résolution. Chaque version beta reçoit plusieurs centaines de corrections, mais de nouveaux problèmes sont également découverts. Donc le nombre de tickets dans l'objectif "R1" baisse beaucoup plus doucement (mais ça baisse quand même). Si on garde le même rythme de -120 tickets tous les 4 ans (environ 30 par ans), on devrait voir la version R1 d'ici environ 18 ans.
Il s'agit d'un rapport trimestriel qui liste les avancées de ces 3 derniers mois uniquement. Pour les 3 mois précédents il faut regarder le rapport précédent, et ainsi de suite. L'équipe est toujours assez réduite (un développeur salarié, une grosse poignée de contributeurs sur leur temps libre, et quelques personnes qui participent de façon plus occasionelle). Cette année, on a entre 7 et 22 contributeurs chaque mois avec un total de 44 personnes différentes sur l'année (la dernière année où il y a eu aussi peu de monde, c'était en 2010, et les chiffres pour 2010 et avant sont faussés parce que on utilisait encore SVN qui ne préservait pas l'auteur pour les contributions externes). On est donc plutôt en effectif réduit par rapport à d'habitude, avec un seul contributeur qui réalise a lui tout seul plus de la moitié des commits (c'était le cas l'an dernier pour la première fois, jusque là, les choses étaient beaucoup plus réparties, mais il n'y avait pas un contributeur salarié à plein temps). Avec environ 1000 à 1500 commits par an, on est loin du record de 2009 ou on avait dépassé 5500 commits. Cependant, les changements de mode de revue du code font que les changements ont tendance à apparaître sous forme d'un seul commit bien testé et finalisé, au lieu de multiples petits changements et correctifs.
On peut aussi regarder du côté de Haikuports, les courbes se sont croisées avec l'introduction en 2012 du gestionnaire de paquets, et on voit beaucoup d'activité sur le portage et le développement de logiciels, plutôt que sur le système lui-même.