[quote=“debian”]Statistiques des bogues critiques pour la prochaine version
Selon l’interface de recherche de bogues dans la base de données
ultime Debian (UDD) [19], la prochaine publication Debian « Wheezy » est
actuellement touchée par 249 bogues critiques pour la publication. En
ignorant les bogues qui peuvent être facilement résolus ou qui sont en
train de l’être, il reste environ 84 bogues critiques pour la
publication à corriger avant que la prochaine version ne puisse
paraître.[/quote]
quand sortira la nouvelle stable il serait bon de mettre au début de SD,tout en haut,un petit tuto avec les quelques commandes permettant la mise à niveau squeeze—>wheezy,c’est pour sûr une question qui reviendra en boucle huit milliard de fois sur le forum,comme l’installation des pilotes nvidia…
Si j’ai le temps je m’y colle dans le Wiki (comme j’avais fait Etch -> Lenny et Lenny -> Squeeze).
Mais je déménage demain… j’ai quelques jours/semaines compliquées à venir.
Pour les mises à jours je me suis un peu emballé… Un paquet devait déconner (ou manquer dans unstable), et du coup j’avais 633 mises à jours à faire. J’ai passé une heure à essayer de résoudre les dépendances, quand un apt-get update à tout remis d’aplomb. une cinquantaine seulement au final.
Oui, j’ai eu quelque chose de similaire ce matin, suite à ton message j’ai voulu faire ma maj, et bizarrement il voulait virer ttf-liberation, ce qui m’a mis la puce à l’oreille !
Un update plus loin, j’ai du avoir une quinzaine ou une vingtaine de paquets à mettre à jour
Usti
PS : en vérifier, c’est un paquet factice de transition, je ferais donc mieux finalement de le virer quand même
On se rend compte qu’il reste beaucoup de travail à faire. Je ne suis pas du tout capable de les aider et je ne veux surtout pas les blâmer, c’est de la simple curiosité.
Je trouve le gel très long, et je me demande vraiment si tout cela est normal ou s’il y a un problème particulier.
J’ai pu lire parfois qu’il y avait un problème hiérarchique dans la gestion des bugs chez Debian, comme un fonctionnement très fermé, assez orienté sur les plus connaisseurs.
Je cherche surtout à savoir comment tout cela fonctionne (je ne pourrais pas du tout aider), et si tout est “normal”.
Permet-moi de te reprendre : ce n’est pas vrai. Ce n’est pas un fonctionnement très fermé, mais un souci constant de qualité.
Mais au contraire, le système debian est très ouvert aux contributions.
Si tu veux aider, à toi de te documenter pour faire les choses bien. Comme ce n’est pas facile, n’hésite pas à demander de l’aide sur les listes de diffusion et à d’autres développeurs debian, ils sont là pour ça.
Pour la sortie de Squeeze les développeurs avaient sortis un tutoriel de migration très bien fait et qui avait été traduit en français très rapidement. J’invite donc à poster ce lien plutôt qu’un sur-tutoriel qui sera moins bien fait. C’est en général un document un peu long mais en réalité il n’y a pas beaucoup de choses qui nous concernent nous utilisateurs classiques. Il y a parfois quelques mises en gardes très particulières mais rien de bien méchant. C’est l’affaire d’une petite demie-heure pour lire + lancer la migration. Le temps de migration dépendra de votre connexion Internet, de votre machine et du nombre de paquets installés
Je n’ai pas de dates en tête, mais il ne me paraît pas plus long que ceux de Squeeze ou Lenny avant lui…[/quote]
+1, vu le nombre de paquets supplémentaires qu’embarquera Wheezy par rapport à Squeeze on peut même dire que la phase de gel est proportionnellement bien plus rapide. Je trouve ça assez remarquable qu’ils arrivent à maintenir à peu près le même temps de stabilisation en ayant à chaque version plusieurs milliers de paquets que la version précédente.
Je t’invite à regarder la définition des bugs sur le site de Debian. Ca peut par exemple être un bug qui a déjà été résolu et la personne qui l’a signalé n’avait pas forcément mise à jour sa distribution avant de remonter le bug. Si les développeurs officiels ignorent ces bugs, c’est que ça se justifie techniquement. C’est la philosophie de Debian : être fiable lorsqu’elle sort pour pouvoir l’utiliser le plus rapidement en production sur des machines critiques comme un serveur.
Ils en ont parlé dans les nouvelles fin 2012 si je me souviens bien. Ils disaient que ça venait principalement de 3 choses :
[ul][li]les développeurs ne sont pas assez nombreux pour enchaîner la correction des bugs facilement. Pas mal d’entre eux font ça sur leur temps libre, donc ce n’est pas évident ;[/li]
[li]un nombre non négligeable de bugs sont liés à des problèmes assez spécifiques de matériel, parfois très peu répandu. Il est donc difficile de détecter d’où vient le bug exactement pour le développeur car la personne qui remonte le bug n’a pas forcément les compétences pour restreindre le champ de recherche et tester en profondeur les patches éventuels. Il faut donc faire pas mal d’échanges de mails pour avancer, c’est assez fastidieux. Par exemple comment résoudre un bug qui affecte un supercalculateur depuis chez toi ? Très peu de personnes ont accès à ce genre de machines et pourtant Debian est destinée à les faire tourner ;[/li]
[li]la faible remontée de bugs : il faudrait que beaucoup plus d’utilisateurs comme toi ou moi qui ne sont pas experts en programmation remontent au moins les bugs qu’ils constatent et envoient des mails pour aider à cerner les problèmes sur les bugs déjà connus. Les développeurs se sont inquiétés du ralentissement des remontées de bugs et ont appelés les utilisateurs à contribuer davantage aux remontées de bugs. Donc n’hésite pas à t’impliquer là dedans si tu souhaites les aider, c’est apparemment ce dont ils ont le plus besoin [/li][/ul]
Cela peut te paraître idiot, mais j’ai souvent pensé à remonter des bugs, même ceux que je jugeais mineurs, mais étant empli de gratitude envers le travail accompli, j’avais l’impression d’être impoli en signalant des problèmes…
Je crois profondément en la stupidité de ma réflexion, et les quelques échanges ici m’auront au moins permis ceci. Faire davantage de tests et ne pas hésiter à écrire un rapport selon les règles précises.
Pour mémoire pour l’avenir, voici un article en 3 parties du responsable de la version 3.2.x du noyau sous Debian qui explique les différences entre la version originale de Linux et celle embarquée dans Debian Wheezy :
Histoire d’en remettre une couche. Quand tu remonte un bug :
[ul]
[li]tu montre que leur travail est utilisé, qu’il a un intérêt[/li]
[li]tu fais un boulot de test qui est particulièrement ingrat pour les développeurs[/li]
[li]tu montre une implication dans leur travail (tu ne te contente pas de dire qu’il y a des bugs ou d’aller ailleurs)[/li]
[li]tu les aides à présenter une très bonne qualité et donc d’avoir un code dont ils peuvent être fier[/li][/ul]
À part si tu es irrévérencieux ils ne te diront jamais que ça les embête.
Fais quand même bien attention à avoir tout ton système à jour avant de cliquer sur “Envoyer le rapport de bug” car il n’est pas impossible que ton bug vienne d’être corrigé dans les 2h précédentes et il serait dommage d’envoyer un rapport pour se rendre compte que c’était inutile. Mais même dans ce cas ça leur montre qu’il y a du monde qui s’implique et j’imagine que c’est ce qui les motive le plus.
On a parfois l’impression que remonter un bug est quelque chose de difficile et fastidieux mais pas tant que ça. Je l’ai fait par exemple l’autre jour pour le logiciel “jaxe” directement sur la page du projet (la version dans Debian est vraiment trop ancienne pour moi donc j’ai utilisé la dernière version prise sur la page officielle) et après un bref échange avec le développeur il a intégré quelques jours plus tard une correction de bug + une amélioration de fonctionnalité. J’imagine qu’il a dû être content de voir que son logiciel servait à d’autres et j’ai moi-même été content de pouvoir contribuer à son amélioration, d’autant plus que ça m’a permis d’avoir très rapidement l’ajout de la fonctionnalité qui me manquait. C’est un rapport gagnant/gagnant, c’est ce qu’il y a de mieux pour développer des projets.
[quote=“seb-ksl”]Ce matin, 238 bugs pour la prochaine release, dont 188 ignorés et 50 en attente d’être patchés. Or 238-188-50=0.
Wheezy arrive ?[/quote]
nous n’avons pas les mêmes chiffres bugs.debian.org/release-critical … sting.html
De toute façon, ça ne sort que quand c’est prêt, pourquoi être impatient ? Au passage, il n’y a toujours pas eu de version RC (release candidate). Wheezy marque le passage au Multiarch, c’est pas une paille et c’est, paraît-il, le but atteint pour cette version Debian.
C’est pas de l’impatience, c’est juste histoire de suivre le gel de debian v.7 autour d’un bon café .
De plus des informations peuvent être mise en avant : la méthode par laquelle les développeurs travaillent, comment remonter un bug, comment faire la(les) mise(s) à jour sans tout casser, le lien sur les objectifs que tu donnes ( dont la mise en place du Multiarch ), etc …
Ça indique aussi que testing ( même gelée ) est " boguée ", et sert surtout à donner des retours aux développeurs pour les aider .
Il y a matière à discussion .
