Moins de bugs en testing qu'en stable en Janvier !

Pause Café
#1

bugs.debian.org/release-critical/

Voici un graphique je j’apprécie beaucoup : le suivi du nombre de bugs répertoriés en testing et en stable. En bleu, les bugs répertoriés pour stable, en vert, ceux pour testing. Courant ce mois de Janvier, testing a eu moins de bugs que stable.

Depuis ma dernière visite, le graphique se retrouve centré sur le cycle en cours. Cela en améliore la lisibilité. Voici le graphique historique :
bugs.debian.org/release-critical/graph.png

On voit les cycles de vie et de parution de releases. Sur un cycle, les bugs de « stable » ne cessent d’augmenter avec de petits soubresauts. Pendant ce temps ceux de testing atteignent rapidement un plafond haut pour ensuite diminuer en dents de scie et rallier l’axe des abscisses (à 0) pour clore le cycle et devenir la prochaine stable.

Pour ma part je pense que je vais passer sur sid prochainement… lorsque la ligne verte sera sous la ligne bleue.

NB : pas sûr que ce soit un « pause café », peut-être un « truc et astuces », posté toutefois en « Pause Café » pour le côté dépêche AFP à la sauce « ma vie ».

#2

Salut,

Mettre tous les bugs dans le même panier en les totalisant n’a qu’un sens très relatif :slightly_smiling:
Certains d’entre eux (gcc 4.4) ont trainé plusieurs années sans gêner personne à ma connaissance !

#3

Mais est-ce que tu connais vraiment beaucoup de monde Gérard ?

#4

Ça vient d’une modification de la politique de gestion des paquets dans testing. Il y a des règles qui font qu’un paquet peut facilement être viré de testing dans les cas où il a un bug RC. C’est assez nouveau, nous en avions parlé lors de la minidebconf le week end dernier. Ça devrait surtout permettre de réduire le temps de freeze de testing.

#5

Merci MisterFreeze pour cette info !

#6

Et surtout les bugs de stable sont les bugs de testing (avant d’etre stable) qui n’avaient pas été repérés.

#7

Quelqu’un aurait des commentaires sur lenny pour la partie 2009, dont le nombre de bugs a suivi la même pente que la future squeeze ?

#8

La testing n’est pas une distribution initialement. Seules existaient sid et la stable, testing n’étant qu’une dénomination de travail. D’ailleurs testing est toujours incomplète sans les apports de la stable ou de sid. Au fur et à mesure du développement d’Ubuntu, testing est devenu une sorte de mi chemin entre unstable et stable avec notamment désormais un minimum de release de sécurité. Je pense que les paquets de testing sont plus sûrs qu’à l’époque de etch. Lenny a été le passage périlleux de l’introduction de udev, l’abandon du devfs avec deux noyaux supportés très différents l’un de l’autre, le passage de 2.6.12 à 2.6.13 et au delà cassait un certains nombres de choses et pourtant cela était nécessaire pour le nouveau matériel (il doit me rester un CD install lenny spécial 2.6.12 que j’avais du concevoir pour un lot de machines à l’époque). Ça peut expliquer les nombreux bugs visibles sur le graphe, mais c’est juste une hypothèse

#9

Salut,

Combien de personnes postent sur ce forum ? J’y passe plusieurs fois par jour. Si connaître les gens c’est être au courant de leurs problèmes, alors je connais pas mal de monde :slightly_smiling:

#10

Comme le remarque fran.b plus haut, il faut prendre ces graphes avec un peu de recul : il y a une différence entre le nombre de bugs rapportés pour une branche et le nombre de bugs l’affectant réellement (ce dernier comprenant aussi les bugs pas encore découverts).

C’est pour ça qu’on peut voir le nombre de bugs grimper en stable sans qu’il ne s’agisse de régressions provoquées par des mises-à-jour.
Plus une distribution est utilisée, plus les bugs sont reportés rapidement. Ça fait grimper le graphe plus vite, mais en réalité ces bugs étaient présents depuis le début.

#11

[quote=“vv222”]Comme le remarque fran.b plus haut, il faut prendre ces graphes avec un peu de recul : il y a une différence entre le nombre de bugs rapportés pour une branche et le nombre de bugs l’affectant réellement (ce dernier comprenant aussi les bugs pas encore découverts).

C’est pour ça qu’on peut voir le nombre de bugs grimper en stable sans qu’il ne s’agisse de régressions provoquées par des mises-à-jour.
Plus une distribution est utilisée, plus les bugs sont reportés rapidement. Ça fait grimper le graphe plus vite, mais en réalité ces bugs étaient présents depuis le début.[/quote]
J’en ai bien conscience… Mais j’imagine que les bugs débusqués dans stable sont à corriger dans sid et stable, donc lorsqu’il commence à y avoir moins de bugs pour sid que pour stable, ça signifie que sid commence à devenir moins risqué à utiliser.

#12

Unstable ne devient jamais “moins risquée” à utiliser : une heure après que tu aies fait ta mise à jour “moins risquée” il peut très bien arriver de nouveaux paquets qui vont te foutre un bazar monstrueux sur ta machine. C’est une cible trop mouvante pour pouvoir être qualifiée autrement que de “tout le temps risquée”.

#13

Mal formulé de ma part, je voulais dire « moins risqué à utiliser [qu’avant] » … Désolé

…L’idée c’est que sid c’est « très sport » après une release de stable parce que ça part dans tous les sens, ensuite ça se calme, et en freeze c’est pépère. Évidemment on n’est jamais à l’abri d’un pépin, mais c’est aussi ça qui est drôle. :smiley:

#14

Il faut bien comprendre l’utilité de la chose. Comparer testing et stable n’a pas beaucoup d’intérêt, mais testing est beaucoup plus utilisée que sid (beaucoup de monde installent testing ou testing/sid sur sa machine de bureau). Retirer les paquets qui ont un bug RC de testing, c’est :
[ul]
[li]améliorer la vie de ces gens (c’est déjà sympa)[/li]
[li]mettre un peu plus de pression sur ces bugs, il faut gérer le gros des problèmes RC avant le freeze (qui sera le 5 novembre au passage)[/li]
[li]améliorer le passage des paquets de unstable à testing (ils ont réduit la durée avant le passage de la première à la seconde de 10 à 5 jours). C’est une nouvelle dynamique pour testing qui n’est donc plus un dépotoir de paquets, mais bien une distribution avec un peu plus de contrôle de qualité qu’avant (Debian CUT perd de son intérêt)[/li][/ul]
La période de freeze devrait s’en trouver vachement réduite (le travail est fait en amont) et ça c’est une bonne nouvelle pour tous les utilisateurs quelque soit la version que vous utilisez. AMHA c’est la nouveauté la plus importante dans Debian depuis bien longtemps (au passage voici l’annonce : lists.debian.org/debian-devel-a … 00006.html).

#15

Tu es sûr de ça, Michel ?
Je ne mets pas en doute cette affirmation si tu as des statistiques fiables mais si ça n’est qu’une impression, j’ai exactement l’inverse.
:017 :017 :017

#16

Non, rien de plus qu’un sentiment.

#17

Je n’ai pas de stats fiables non plus, seulement un sentiment concernant un tout petit échantillon (la population de debian-fr), mais je suis aussi de l’avis de ricardo : j’ai l’impression qu’il y a bien plus de sid dans l’ensemble. Enfin je peux me planter vu que j’évalue ça au doigt mouillé. :wink:

#18

Ça dépend de quel doigt il s’agit et de l’origine de son humidité :laughing: :laughing: :laughing:
J’ai (presque) honte :blush:

#19

Pour ce qui est de Testing ou Sid, si je peux donner mon avis, dans mon entourage des utilisateurs de GNU/Linux, il est vrai que beaucoup de personnes utilisent Sid pour un usage privé. (Sans compter le nombre très grand d’utilisateur de Ubuntu.)

Mais je travaille égallement en collaboration avec une entreprise qui se base sur des outils OpenSource, et chez eux la pollitique c’est:
Debian Testing pour les desktops.
Debian Stable pour les serveurs.

#20

[quote=“DragaoAzul45”]Pour ce qui est de Testing ou Sid, si je peux donner mon avis, dans mon entourage des utilisateurs de GNU/Linux, il est vrai que beaucoup de personnes utilisent Sid pour un usage privé. (Sans compter le nombre très grand d’utilisateur de Ubuntu.)

Mais je travaille égallement en collaboration avec une entreprise qui se base sur des outils OpenSource, et chez eux la pollitique c’est:
Debian Testing pour les desktops.
Debian Stable pour les serveurs.[/quote]

du coup pas de reinstall/mise à jour de version sur les desktops