Outils développeurActualité

GNOME : RFC et qualité des extensions, deux pistes

Sur cette page
  1. Une proposition n’est pas une règle adoptée
  2. Un cycle de vie simple explique le coût
  3. Deux traces de revue différentes

Une discussion de gouvernance et un guide de revue sont apparus la même semaine. Ils répondent à des problèmes voisins, sans que l’un soit devenu automatiquement la politique de l’autre.

Cycle de vie conceptuel : activer crée un temporisateur et conserve son identifiant ; désactiver retire la source et vide la référence avant réactivation. Masquer le panneau seul ne termine pas le temporisateur.
Cycle de vie conceptuel : activer crée un temporisateur et conserve son identifiant ; désactiver retire la source et vide la référence avant réactivation. Masquer le panneau seul ne termine pas le temporisateur. Graphique : PeopleAreGeek. Source des données.
Agrandir l’image

Une proposition n’est pas une règle adoptée

La discussion du 27 juillet de Sophie Herold propose un cadre RFC, puis un retour collectif avant de l’appliquer à lui-même. Décisions, parties prenantes et lieu de débat sont discutés. Le fil démontre une proposition, pas l’adoption d’une politique IA définitive.

Séparément, le guide de Javad Rahmatzadeh demande aux auteurs de comprendre JavaScript et d’entretenir leur code. Nettoyage, signaux, temporisateurs et séparation des processus sont des préoccupations concrètes, quelle que soit l’origine du brouillon.

Un cycle de vie simple explique le coût

Supposons qu’une extension démarre un temporisateur à chaque activation. Si la désactivation masque seulement son panneau, les rappels peuvent continuer. Une nouvelle activation peut ajouter un second temporisateur. Une fonction apparemment correcte accumule alors des rappels et des références à une interface qui n’existe peut-être plus.

Notre schéma associe création et nettoyage : créer une source, conserver son identifiant, la retirer à la destruction et vider la référence. La même question de responsabilité concerne signaux et travail asynchrone annulable. C’est un exemple explicatif, pas une extension testée ni une recette universelle.

Deux traces de revue différentes

Pour le code, il faut identifier le propriétaire de chaque ressource, sa libération et le comportement lors d’activations répétées. Pour la gouvernance, il faut conserver décision, solutions envisagées et personnes ayant accepté le compromis. Une proposition soignée ne démontre pas le nettoyage à l’exécution ; une extension fonctionnelle ne prouve pas un consensus du projet.

La distinction rend les deux documents exploitables. Les contributeurs peuvent appliquer les consignes existantes et suivre le débat RFC pour comprendre l’évolution du processus collectif. Présenter le tout comme une nouvelle règle anti-IA adoptée masquerait à la fois le périmètre et l’état réel de ces travaux.

Revue du 8 septembre : proposition de gouvernance séparée des consignes de revue ; politique supposée adoptée retirée et responsabilités de cycle de vie précisées.