J'ai mal posé une question : ton rapport trimestriel liste les travaux de ce trimestre, mais est-ce que certains de ces travaux ont par exemple duré 10 mois ?
Je ne crois pas pour ce trimestre, ça arrive parfois et dans ce cas j'essaie de le mentionner (j'espère qu'on pourra bientôt parler du redimensionneur de partitions BFS, pour lequel le travail a commencé en 2014 pendant le Google Summer of Code mais n'a pas pu être terminé à l'époque).
Au fait où en sont les travaux sur le portage RiscV ?
Il n'y a plus de travaux puisque c'est fini :)
Une machine RISC-V tourne en continu pour compiler les paquets de Haikuports pour RISC-V. Il est possible qu'on l'ajoute à la liste des architectures supportées pour la beta 6 ou la 7.
Vu que vos versions Alphas étaient déjà stables et qu'après bientôt 30 ans plus personne ne comprend la numérotation de BeOS, vous pourriez aussi bien nommer les prochaines Bétas en v1, v2, etc.
Je ne sais pas si je suis trop exigeant avec mon système ou si les autres personnes sont beaucoup trop tolérantes aux pannes.
Sur ma machine, les kernel panics sont relativement fréquents (disons entre une fois par semaine et une fois par mois). Les retours de personnes qui essaient vraiment sérieusement d'utiliser Haiku (pas juste pour s'amuser) sont similaires: par exemple les développeurs de NetSurf qui essaient de l'intégrer dans leur système d'intégration continue ont remonté plusieurs problèmes, certains que l'on a pu corriger, d'autres pas encore.
Changer la numérotation des versions ne règlera pas ces problèmes. Ce serait donc malhonnête envers les utilisateurs et un risque de se prendre une volée de bad buzz.
De plus, nous sommes actuellement incapables de livrer des versions au moins tous les ans comme ça devrait être le cas (pour des problèmes de process de développement, de changements qui causent des régressions, d'absence de tests automatisés, ...). Souvent, les logiciels en cours de développement utilisent des fonctionnalités disponibles uniquement dans les versions "nightly build" et sont donc en incapacité de livrer des versions fonctionnant sur la dernière release publiée. On peut se permettre ce genre de fantaisie pour un système en beta, mais pas pour quelque chose qu'on encourage les gens à utiliser comme leur système principal auquel confier tout leur travail. Il faut donc au moins qu'on travaille sur ce process de livraison, notre façon de gérer les branches de développement, et tout ça. Des choses qui prendraient du temps et ralentiraient encore le développement. On a pas vraiment les ressources pour se le permettre.
En gros, pour moi, la version 1 de Haiku, ce sera quand je me sentirai prêt à l'installer par exemple chez mes parents (qui ne sont pas de grand spécialistes de l'informatique) et à ne pas avoir à intervenir pour réparer des choses. On est loin du compte, mais en attendant, ça n'empêche pas de l'utiliser pour des personnes avec un profil un peu plus "bricoleur" ou habitués à se débrouiller avec un ordinateur un peu déréglé. Ce que je fais d'ailleurs moi-même. Ce n'est donc pas important que cette version arrive un jour ou pas. L'important c'est que chaque version soit mieux que la précédente, que les quelques utilisateurs existants soient satisfaits, et qu'on en récupère quelques nouveaux de temps en temps.
[^] # Re: plein de questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 10.
Je ne crois pas pour ce trimestre, ça arrive parfois et dans ce cas j'essaie de le mentionner (j'espère qu'on pourra bientôt parler du redimensionneur de partitions BFS, pour lequel le travail a commencé en 2014 pendant le Google Summer of Code mais n'a pas pu être terminé à l'époque).
Il n'y a plus de travaux puisque c'est fini :)
Une machine RISC-V tourne en continu pour compiler les paquets de Haikuports pour RISC-V. Il est possible qu'on l'ajoute à la liste des architectures supportées pour la beta 6 ou la 7.
Je ne sais pas si je suis trop exigeant avec mon système ou si les autres personnes sont beaucoup trop tolérantes aux pannes.
Sur ma machine, les kernel panics sont relativement fréquents (disons entre une fois par semaine et une fois par mois). Les retours de personnes qui essaient vraiment sérieusement d'utiliser Haiku (pas juste pour s'amuser) sont similaires: par exemple les développeurs de NetSurf qui essaient de l'intégrer dans leur système d'intégration continue ont remonté plusieurs problèmes, certains que l'on a pu corriger, d'autres pas encore.
Changer la numérotation des versions ne règlera pas ces problèmes. Ce serait donc malhonnête envers les utilisateurs et un risque de se prendre une volée de bad buzz.
De plus, nous sommes actuellement incapables de livrer des versions au moins tous les ans comme ça devrait être le cas (pour des problèmes de process de développement, de changements qui causent des régressions, d'absence de tests automatisés, ...). Souvent, les logiciels en cours de développement utilisent des fonctionnalités disponibles uniquement dans les versions "nightly build" et sont donc en incapacité de livrer des versions fonctionnant sur la dernière release publiée. On peut se permettre ce genre de fantaisie pour un système en beta, mais pas pour quelque chose qu'on encourage les gens à utiliser comme leur système principal auquel confier tout leur travail. Il faut donc au moins qu'on travaille sur ce process de livraison, notre façon de gérer les branches de développement, et tout ça. Des choses qui prendraient du temps et ralentiraient encore le développement. On a pas vraiment les ressources pour se le permettre.
En gros, pour moi, la version 1 de Haiku, ce sera quand je me sentirai prêt à l'installer par exemple chez mes parents (qui ne sont pas de grand spécialistes de l'informatique) et à ne pas avoir à intervenir pour réparer des choses. On est loin du compte, mais en attendant, ça n'empêche pas de l'utiliser pour des personnes avec un profil un peu plus "bricoleur" ou habitués à se débrouiller avec un ordinateur un peu déréglé. Ce que je fais d'ailleurs moi-même. Ce n'est donc pas important que cette version arrive un jour ou pas. L'important c'est que chaque version soit mieux que la précédente, que les quelques utilisateurs existants soient satisfaits, et qu'on en récupère quelques nouveaux de temps en temps.