Merci à Bernard Gisbert pour sa relecture. Pas d'autre commentaire ? -- Thomas Huriaux
#use wml::debian::template title="Retranscription du débat" #use wml::debian::translation-check translation="1.12" maintainer="Thomas Huriaux" <h2>Introduction</h2> <b>Rob :</b> Bonjour et bonsoir à tout le monde. :) Bienvenus au débat du chef de projet Debian 2000. Je suis votre modérateur, Rob Levin, le chef des opérations des projets ouverts. <br><b>Rob :</b> Nous vous avons tous rassemblé ici pour pouvoir avoir un forum public sur lequel les candidats peuvent se présenter et expliquer ce qu'ils peuvent apporter au poste de chef de projet Debian. Comme vous avez pu le voir sur le site web, ce débat sera divisé en deux parties : une série de questions et réponses formelles suivie d'une série de questions et réponses informelles proposées par les participants. Pour soumettre une question pour la deuxième partie, envoyez un courriel à dld2k@openprojects.net. <br><b>Rob :</b> Faites des questions anonymes ; nous allons essayer de les trier au mieux possible, mais toutes les questions seront envoyées sans les en-têtes après le débat, de manière à ce que les candidats et d'autres personnes puissent les voir et y répondre. Nous faisons de notre mieux, donc soyez gentils, s'il vous plaît :) Les inondations de questions devront probablement être retirées, donc n'exagérez pas. <br><b>Rob :</b> Nos candidats sont Ben Collins, Wichert Akkerman, Joel Klecker et Matthew Vernon. <br><b>Rob :</b> Nous allons essayer de fournir 3 minutes par réponse et par candidat pendant la série de questions formelles. Nous pourrons laisser plus de temps si nécessaire, mais nous voulons permettre à l'audience d'en poser également. <br><b>Rob :</b> Lorsque vous envoyez des questions informelles à dld2k@openprojects.net, veuillez vous assurer que l'en-tête commence avec QUESTION. <br><b>Rob :</b> Merci. <h2>La distribution entièrement libre de RMS</h2> <hr> Il y a quelques temps, <a href="$(HOME)/News/weekly/1999/1/">RMS a demandé à Debian</a> une distribution qui n'incluait ni logiciel non libre, ni référence à ceux-ci. Beaucoup d'idées ont été proposées pour répondre à cette requête. Qu'est-ce que devrait faire Debian, s'il doit faire quelque chose ? <hr> <p><b>Matthew :</b> Comme je le comprends, nous le faisons déjà d'une façon plus ou moins étendue – main ne contient que des logiciels libres, et tout ce qui dépend de choses non libres est dans contrib. La question si les paquets devraient suggérer ou recommander des choses non libres est différente. <br><b>Matthew :</b> AMHA, cela serait mieux que ce ne soit pas le cas, mais s'il n'y a pas d'alternative libre, cela semble être non réprimandable de fournir l'information pertinente. <br><b>Rob :</b> Matthew : as-tu des commentaires supplémentaires ? <br><b>Matthew :</b> Je peux comprendre l'opinion de RMS, mais je pense qu'essayer de cacher le fait que « truc » est amélioré par « machin » n'est pas beaucoup bénéfique. <p><b>BenC :</b> OK... AMA, nous commençons déjà à voir apparaître cela. Comme pour tout, il faut du temps pour changer des choses qui fonctionnent d'une certaine manière depuis si longtemps. <br><b>BenC :</b> Je crois que nous ne devrions pas complètement « cacher » non-free, puisque c'est en contradiction avec nos convictions actuelles de gérer et reconnaître que le logiciel non libre existe. <br><b>BenC :</b> Les avancées dans la gestion de notre archive (dépôts de paquets, etc.) et les outils pour les paquets (apt) vont nous permettre de donner à l'utilisateur un choix clair dans l'utilisation de logiciels non libres. <br><b>BenC :</b> L'éducation est meilleure que le passage en force. <p><b>Wichert :</b> Je pense que les gens savent déjà que je soutiens l'idée ; j'ai déjà proposé de le faire cette année, mais cela ne s'est pas concrétisé car c'est difficile à diviser, nous ne savons pas exactement comment le faire et nous avons découvert d'autres choses qui ont eu besoin d'attention immédiate. <br><b>Wichert :</b> L'idée d'avoir une distribution qui n'utilise que des logiciels libres et n'a besoin de rien d'autre me plaît, et si nous pouvons le faire sans diminuer notre gestion des logiciels non libres, je pense que nous devrions vraiment le faire. <br><b>Wichert :</b> Prouver que vous pouvez vivre sans logiciel non libre n'est pas aussi sévère que de les cacher. Nous aurons et gérerons toujours des logiciels non libres. <h2>Fermeture de l'accès aux nouveaux responsables</h2> <hr> Pendant votre candidature, <a href="http://lists.debian.org/debian-devel-announce-9910/msg00003.html";>\ le processus d'accès aux nouveaux responsables a été arrêté par l'équipe en charge de ces nouveaux responsables</a>. Beaucoup de personnes ont considéré leur action comme inappropriée. Comment est-ce que les actions unilatérales et inappropriées prises par des délégués ou des équipes devraient être traitées par le projet ? <hr> <p><b>Wichert :</b> L'accès aux nouveaux responsables est actuellement peut-être un mauvais exemple. Les personnes en charge de ce processus ont une fonction vraiment importante dans Debian. Celles dans le comité peuvent aussi bien transformer quelqu'un en développeur que lui retirer son statut de développeur. <br><b>Wichert :</b> Je suis d'accord que l'accès a été formé un peu trop longtemps et qu'il aurait fallu faire quelque chose plus tôt. <br><b>Wichert :</b> Cependant, dans ce cas, sachant que a) il s'agit d'un travail très important pour lequel vous ne pouvez pas facilement remplacer les personnes, et b) nous avions des personnes dans l'équipe qui voulaient continuer à essayer de fournir une bonne nouvelle structure pour le gérer, j'ai hésité énormément pour les remplacer. <br><b>Wichert :</b> J'espère que l'avenir montrera que c'était la bonne décision, mais nous devons attendre avant de voir comment les choses évoluent. <br><b>Wichert :</b> Plus généralement, je ne pense pas qu'un délégué doit être traité différemment par rapport aux autres responsables. Si quelqu'un n'est pas actif, nous devons essayer de l'impliquer et de le faire participer davantage. Si cela semble impossible, nous devons le remplacer. <p><b>Matthew :</b> Je pense que cela doit être géré au cas par cas. Dans le cas des nouveaux responsables, il semble que le problème aurait pu être détecté avant que le malheur arrive. Sachant cela, si une équipe décide qu'elle en a assez, nous ne pouvons (et ne devrions) pas les forcer à continuer à faire leur tâche. Je propose de rester en contact avec tous les groupes semblables, de manière à les encadrer si les choses commencent à aller mal et à prendre les mesures appropriées, en prévention. <br><b>Matthew :</b> Je ne vais pas commencer à reprocher aux personnes la façon dont a été géré l'accès aux nouveaux responsables, en particulier s'il va bientôt être réouvert. <br><b>Matthew :</b> Dorénavant, la chose importante à ce sujet est d'aller de l'avant. <br><b>Matthew :</b> En général, une meilleure communication devrait éviter ce genre de choses – et je pense que c'est vraiment important. <p><b>Ben :</b> Je pense que ma position sur « l'échec des nouveaux responsables » diffère, car je pense que cela a plus à voir avec quelques questions principales dans notre structure... <br><b>Ben :</b> Après avoir parlé à quelques personnes impliquées dans l'accès aux nouveaux responsables, je me suis rendu compte qu'elles demandaient déjà de l'aide bien avant qu'elles ne décident de le fermer. Elles le demandaient indirectement, mais elles le demandaient quand même. <br><b>Ben :</b> Je pense que personne ne peut accuser quelqu'un, puisque personne n'est fautif. Nous n'étions tout simplement pas préparés à gérer un tel événement. Il y aura des changements importants dans le futur, puisque nous avons besoin d'une meilleure structure pour gérer nos fonctionnalités principales... les choses comme l'administration des FTP, l'administration système, l'accueil des nouveaux responsables, etc. <br><b>Ben :</b> Il n'y a pas de structure bien définie pour s'assurer que ces fonctions (en dehors des personnes) ne risquent pas de s'effondrer à un moment. <br><b>Ben :</b> Cela doit changer. <h2>La croissance continue, responsables dont on est sans nouvelle et question de délégation</h2> <hr> La <a href="http://kitenet.net/programs/debhelper/stats/numpackages.gif";>\ croissance récente de Debian a été impressionnante</a>. Le projet a quasiment doublé en taille dans tous les domaines. Est-ce que cette croissance est supportable ? Est-ce que quelque chose devrait être fait pour rendre Debian plus évolutif ou pour en réduire la taille ? <hr> <p><b>Matthew :</b> Comme je l'ai dit dans mon discours d'ouverture, la communication semble être la clé pour gérer la croissance. <br><b>Matthew :</b> Le chef de projet doit rester en contact avec les différents groupes (administrateurs des FTP, équipe des nouveaux responsables, assurance qualité, etc.) pour s'assurer qu'ils sont heureux et que tout va bien. Les tâches qui auparavant ne demandaient qu'une ou deux personnes vont nécessiter de plus en plus de monde, et le chef de projet devra coordonner tout cela. <p><b>Ben :</b> OK, je déteste de faire des commentaires directs sur la réponse d'un autre candidat, mais c'est un débat :) <br><b>Rob :</b> BenC : c'est autorisé. <br><b>Ben :</b> Je ne suis pas d'accord que nous sommes dans un état gérable actuellement. Il y a beaucoup de tâches nécessaires qui ne peuvent être réalisées pour le moment. Retirer le désordre parmi nos 4 000 paquets et nos plus de 7 architectures est la prochaine des choses à faire à tout prix. <br><b>Ben :</b> Nous aurons à mettre en place un meilleur contrôle de notre archive... <br><b>Ben :</b> La communication n'est également pas la réponse à tout... Sans avoir de base fonctionnant sur laquelle se développer (chartes bien définies pour chaque groupe), nous ne pouvons pas savoir à qui parler, ou qui doit prendre une décision vitale pour supporter la croissance. <p><b>Wichert :</b> Actuellement, nous semblons correctement gérer la croissance, et je pense que cela apporte beaucoup de bonnes choses. Cependant, cela signifie que nous aurons à examiner constamment notre organisation et voir si des choses doivent être changées. Nous l'avons déjà fait en créant des listes comme debian-devel et debian-private, une équipe en charge des nouveaux responsables, une constitution, etc. Comme je l'ai également déjà dit dans mon discours d'ouverture, nous devrons aussi nous concentrer sur des domaines comme le contrôle de la qualité. <br><b>Wichert :</b> Je pense que nous avons atteint le point à partir duquel une seule personne ne peut plus être au courant de tout ce qui se passe au sein de Debian, et nous aurons besoin de voir comment cela peut influencer le projet. Je pense que nous aurons cette année à décider comment nous devrions gérer des « projets » qui se concentrent sur des domaines spécifiques de debian, comme les disquettes de démarrage, le contrôle de la qualité, la documentation, la gestion de l'archive, etc. <br><b>Wichert :</b> Cela signifie sans aucun doute qu'il y aura des réticences, puisqu'il sera plus difficile pour les gens de suivre tout. Espérons que des choses comme la gazette hebdomadaire de Debian nous aideront. <h2>Debian BSD et Hurd</h2> <hr> Deux sous-projets au sein de Debian sont destinés à développer des portages de Debian sur le <a href="$(HOME)/ports/hurd/">Hurd</a> et sur des <a href="http://master.debian.org/~dexter/debian-freebsd/doc/whatisit";>\ plates-formes BSD</a>. Certains des plans suggérés rendraient ces portages considérablement différents de la plate-forme Linux. À quel point ces portages peuvent-ils dévier des autres plates-formes ? Debian devrait-il se concentrer sur sa distribution Linux principale ou essayer de s'étendre à d'autres systèmes d'exploitations ? <hr> <p><b>Matthew :</b> Bien, en tant que participant au Hurd, mon regard peut être un petit peu biaisé, mais je ne vois aucun problème à avoir des systèmes d'exploitation non basés sur Linux qui fassent partie de Debian. <br><b>Matthew :</b> Tant que ces systèmes d'exploitation sont libres et ne rentrent pas en conflit sur trop de points avec la charte (GNU/Hurd, par exemple, utilise shadowfs (ou l'utilisera), ce qui signifie qu'il pourrait ne pas faire la distinction entre /bin et /usr/bin). <br><b>Matthew :</b> Je pense que c'est une bonne chose, mais cela crée clairement des problèmes que notre infrastructure ne sait pas bien gérer (par exemple, le champ <i>Architecture:</i> spécifié à <i>all</i> est de moins en moins fréquent, et il y a des bogues spécifiques à certains systèmes dans des paquets). <br><b>Matthew :</b> Si nous pouvons résoudre ces questions, alors je pense que les portages sur des systèmes non-Linux rendront Debian plus flexible et plus attractive pour les administrateurs. <br><b>Matthew :</b> Nous devrions cependant maintenir nos efforts sur Linux dans le futur proche. <p><b>Ben :</b> Je pense que l'idée de proposer des systèmes alternatifs fait entièrement partie de l'héritage de Debian... <br><b>Ben :</b> Linux était dans cet état au démarrage de Debian, donc ce n'est pas en dehors de nos convictions tant que nous adhérons aux idées de liberté, ce que BSD et le Hurd font également. <br><b>Ben :</b> Il semble évident que les groupes gérant de tels portages devraient être responsables de la division et de la maintenance pour permettre à leur système d'exploitation de cohabiter avec notre archive pour Linux... en même temps, les autres développeurs devraient accepter ces changements et aider les groupes lorsque cela est possible, avec des idées et des commentaires. <br><b>Ben :</b> Je pense que l'obstacle principal est de garder une approche spécifique à Intel et Linux. Les bogues et les changements qui affectent des architectures non-Intel, voire les portages non-Linux, ne sont pas considérés avec la même priorité. <br><b>Ben :</b> Cela est en train de changer, mais cette approche doit disparaître complètement. <p><b>Wichert :</b> Cela est différent pour chaque portage. De ce que je connais du portage BSD, la stratégie est d'avoir un petit système de base BSD et d'utiliser la gestion de compatibilité de FreeBSD à Linux pour faire tourner l'espace utilisateur GNU/Linux normal, ce qui signifie que nous n'avons pas besoin de faire beaucoup pour le gérer. <br><b>Wichert :</b> En ce qui concerne le Hurd, nous allons probablement voir de plus en plus de paquets spécifiques au Hurd, ce qui ne devrait pas être un problème. <br><b>Wichert :</b> Certains paquets poseront cependant problème, puisqu'ils nécessiteront des changements importants en fonction du système d'exploitation. <br><b>Wichert :</b> Je ne pense pas que nous sachions vraiment pour le moment comment nous devrions gérer ces questions, donc je pense que nous devons attendre et voir comment cela évolue. <br><b>Wichert :</b> Pour l'infrastructure, comme Matthew l'a dit, nous aurons besoin d'y appliquer quelques changements. <br><b>Wichert :</b> Par exemple, pour le moment, nous n'avons pas de branches binary-all par architecture, ce dont nous aurons besoin à un certain moment. <br><b>Wichert :</b> Pour le moment nous nous concentrons principalement sur Linux (et i386), car c'est ce qu'utilisent principalement nos développeurs. <br><b>Wichert :</b> Cela pourrait cependant changer dans le futur, mais nous ne pouvons en aucun cas le prédire. <h2>Rôle de la cabale</h2> <hr> Est-ce que certaines personnes ou certains groupes ont <a href="http://lists.debian.org/debian-devel-9909/msg01095.html";>de l'influence voire du pouvoir</a> qui n'est pas spécifié dans la <a href="$(HOME)/devel/constitution">constitution</a> ? Si oui, est-ce bon ? mauvais ? Qu'est-ce qui devrait être fait, s'il y a quelque chose à faire ? Si ces personnes n'existent pas, que devrions nous faire pour éteindre le <a href="http://lists.debian.org/debian-devel-9910/msg01412.html";> mythe de la cabale</a> ? <hr> <p><b>Wichert :</b> Bien sûr que personne n'a de pouvoir en dehors de ce qui est écrit dans la constitution. <br><b>Wichert :</b> La théorie de la « cabale » suggère qu'un petit groupe de personnes a (presque) tout le pouvoir sur Debian. <br><b>Wichert :</b> Ce qui se passe actuellement est qu'un petit groupe de personnes passe <strong>beaucoup</strong> de temps sur Debian. <br><b>Wichert :</b> En résultat, ce groupe se connaît mieux que quiconque, et est actif dans beaucoup de domaines du projet. <br><b>Wichert :</b> Cela ne veut pas dire que c'est un groupe fermé ou qu'il s'agit d'une aristocratie. <br><b>Wichert :</b> Tout le monde peut rejoindre n'importe quel domaine du projet, et nous encourageons les personnes à le faire. <br><b>Rob :</b> OK, nous avons atteint la limite de temps. <br><b>Wichert :</b> Tu veux dire que mon temps est écoulé ? <br><b>Rob :</b> Oui, trois minutes. <p><b>Matthew :</b> Inévitablement, dans une organisation de la taille de Debian, certaines personnes vont rencontrer en personne le chef de projet, et peuvent donc sembler avoir de l'influence sur lui. En pratique, il s'agit d'une question de maturité pour le chef de projet. Je ne doute pas qu'aucun des candidats ne soit suffisamment bon dans ce domaine. En ce qui concerne la cabale, il y a certainement quelques personnes qui passent beaucoup de temps sur debian et/ou beaucoup de temps sur IRC, donc qui peuvent très bien se mettre d'accord pour contrer quelque chose. <br><b>Matthew :</b> Les autres peuvent considérer qu'une « cabale » règne sur Debian. <br><b>Matthew :</b> Que ces personnes aient ou non de l'autorité est discutable. Je ne vois cependant pas comment on pourrait diminuer les rumeurs d'une cabale – beaucoup des groupes au sein desquels je participe ont une cabale légendaire d'une manière ou d'une autre. <br><b>Matthew :</b> Dans un groupe de la taille de Debian, les accusations de cercles fermés ou de cabale seront toujours présentes. <br><b>Matthew :</b> Tant qu'il n'y a pas de réelle cabale, ce n'est pas un problème, AMA. <p><b>Ben :</b> Je pense que nous sommes tous plus ou moins d'accord sur cette question... les théories et les accusations ne disparaîtront jamais complètement, quoi que l'on fasse. D'un côté, l'interaction en temps réel entre les développeurs sur IRC ou dans la vie réelle est une bonne chose... Les choses sont réalisées plutôt rapidement, et avec peu ou sans histoires... ce qui permet de progresser. Tout contraindre avec des « chartes » n'est en général pas souhaitable. <br><b>Ben :</b> Cependant, la contrepartie est que cela donne un air de politique de « porte fermée ». <br><b>Ben :</b> Les gens se sentent laissés en arrière. <br><b>Ben :</b> Ainsi, le résultat final contiendra probablement une sorte de médiane... Et tous les cas sont différents pour la définition de médiane, qui est donc subjective. Pour être honnête, je ne sais pas comment éviter que cela se reproduise, mais si je suis chef de projet, j'essaierai de le réduire. <hr> <h2>Argent et idéaux</h2> <hr> Le <a href="http://lwn.net/stocks/";>lancement récent d'ouvertures du capital</a> et de startups a créé beaucoup de capitaux disponibles pour le monde du logiciel libre. Comment cela devrait-il influencer Debian et ses idéaux d'être une distribution <a href="$(HOME)/social_contract#guidelines">libre</a> et <a href="http://ftp.debian.org/debian/doc/debian-manifesto";>excellente au niveau technique</a> ? Quelle est l'influence que des entités commerciales (en particulier celles impliquées dans le <a href="http://opensource.corel.com/corel_linux_os.html";>développement de notre base</a>) peuvent avoir sur le projet ? <p> et : <p> Le projet jouit d'un <a href="$(HOME)/News/1997/shuttle1">passé réussi</a> mais Linux est dorénavant <a href="http://news.cnet.com/news/0-1003-200-1546430.html?tag=st.ne.1002.bgif?st.ne.fd.gif.j";>\ presque tendance</a>. Comment Debian va-t-il réagir à cela, et à quel moment (1, 5 ou 10 ans à partir de maintenant) ? <hr> <p><b>Ben :</b> Hum... question plutôt large pour 3 minutes :) <br><b>Ben :</b> Principalement, je pense que nous devrions simplement conserver nos objectifs... fournir une large sélection de logiciels dans le format le plus stable possible... <br><b>Ben :</b> Le moment où nous commencerons à laisser des entités commerciales influencer nos prises de décisions sera le moment où Debian arrêtera d'être Debian. <br><b>Ben :</b> Nous devrions simplement accepter le fait que nous sommes observés par ces entités, mais pas les ignorer... juste les considérer comme des groupes importants d'utilisateurs moyens :) <p><b>Wichert :</b> \#include « le commentaire de BenC » <br><b>Wichert :</b> Nous sommes déjà influencés. Nous avons vu des personnes voulant devenir responsable Debian pour la seule raison de pouvoir participer à une ouverture du capital. Nous en bénéficions également. <br><b>Wichert :</b> Sans cet énorme intérêt pour Linux et les capitaux qui deviennent disponibles, nous n'aurions pas les ressources que nous avons aujourd'hui... VA n'aurait pas embauché deux développeurs à plein temps, par exemple. <br><b>Wichert :</b> Cela touche également nos développeurs, puisque certains d'entre eux ont bénéficié de leur implication dans Linux ou dans le logiciel libre en général. <br><b>Wichert :</b> Je ne pense cependant pas que cela a influencé ou va influencer Debian lui-même. Nous avons encore tous pour objectif de faire un système d'exploitation libre en tant que projet ouvert. Et je ne pense pas que cela va nous changer. <p><b>Matthew :</b> AMA, Debian va (et devrait) rester une organisation de volontaires. C'est notre nature, et c'est important. De cette manière, nous pouvons nous concentrer pour faire la meilleure distribution, sans avoir à s'inquiéter des pressions commerciales. <br><b>Matthew :</b> Pour répondre à la question de comment les entités commerciales devraient nous influencer, je ne pense pas qu'elles devraient avoir plus d'influence que les utilisateurs normaux. <br><b>Matthew :</b> Je pense que la mise à la mode (est-ce une expression qui existe ?) de Linux ne peut que nous être bénéfique, en attirant des développeurs plus compétents (et espérons de l'argent :)). <br><b>Matthew :</b> Dans 10 ans, je nous vois toujours comme la meilleure distribution au monde :) <h2>Questions ouvertes</h2> <p><b>Rob :</b> Fantastique ! <br><b>Rob :</b> OK, nous passons à l'étape suivante. <br><b>Rob :</b> Je prie tout le monde de m'excuser pour l'heure ; c'est vraiment difficile de mettre tout cela dans un même format. <br><b>Rob :</b> Nous allons faire une pause de 10 minutes. <br><b>Rob :</b> Pendant cette période, rien ne sera modéré. <br><b>Rob :</b> Messieurs les candidats, veuillez rester calmes pendant la pause :) <br><b>Jason:</b> Je vais poster la liste complète des sujets sur la liste de diffusion, nous en avions initialement 12 à discuter. <br><b>Rob :</b> OK tout le monde... gardez à l'esprit qu'au moins un de nos participants a des contraintes horaires (il doit quitter dans 15 minutes). <br><b>Rob :</b> Nous allons poser deux questions courtes, puis proposer un bref résumé. <h2>KDE et Debian</h2> <hr> La position actuelle de Debian à propos de KDE est de ne pas l'inclure. Les programmeurs de KDE et d'autres distributions n'ont aucun problème avec la licence actuelle. Est-ce que Debian devrait modifier sa position en fonction des questions de licences de KDE ? <hr> <p><b>Matthew :</b> Bien, comme je le comprends, le problème est que certaines parties de KDE incluent du code sous GPL, alors que la QPL n'est pas compatible avec la GPL. Il y a eu beaucoup de discussions sur -legal. <br><b>Matthew :</b> Ma position sur ce sujet est que s'il n'y a pas de problème pour l'inclure, alors nous devrions le faire. S'il y en a, alors nous ne devrions pas. Aussi simple que cela. Je laisse les experts en licences décider si c'est le cas. Ce que font les autres distributions ne compte pas – nous devons faire ce qui est bon, AMHA. <p><b>Wichert :</b> Je ne peux rien faire d'autre que d'être d'accord. Debian n'est rien sans le logiciel libre, et nous ne devrions pas permettre à quelque chose comme cela de nous gêner. Si possible, nous devrions les aider à résoudre ces questions pour que tout le monde puisse en bénéficier, mais c'est un problème réel pour le moment. <p><b>Ben :</b> Je pense qu'il s'agit réellement d'une question légale..., une qui ne peut pas être résolue seulement sur une opinion. Je suis d'accord avec Matthew et Wichert... mais la solution n'est pas claire et je ne suis pas juriste :) <h2>Cycle de publication et dépôts de paquets</h2> <hr> Que ferez vous pour accélérer les cycles de publication de Debian ? <br> et : <br> Avec la croissance de Debian et près de 5 000 paquets, il est dorénavant clair que le système de paquets actuel est dépassé. De plus, avec les cycles de publication lents, il semble qu'il n'y ait que des distributions « cassées » ou « obsolètes ». Ma question est donc si vous désirez introduire des dépôts de paquets (décrits sur http://lists.debian.org/debian-project-9910/msg00052.html). Et dans le cas contraire, que voyez-vous comme autre alternative ? <hr> <p><b>Matthew :</b> Je n'ai pas examiné en détails les dépôts de paquets (et je n'ai pas le temps de le faire en 2 minutes). En ce qui concerne les cycles de publication, je pense que nous avons besoin de permettre moins de temps entre une publication et le gel suivant – de cette façon nous pourrons avoir des publications plus fréquentes sans toutefois diminuer le temps de gel. <br><b>Matthew :</b> Des périodes plus courtes entre la publication et le gel suivant laisseraient moins de bogues dans la distribution. Avec plus d'attention portée à l'assurance qualité, nous pourrions avoir des personnes travaillant plus spécifiquement sur les objectifs de publication pour la prochaine sortie. <br><b>Matthew :</b> Et moins de nouvelles choses dans une publication signifie également moins de bogues – nous devons trouver l'équilibre entre les publications très fréquentes avec très peu de nouvelles choses (une situation extrême que les distributeurs détesteraient), et des publications moins fréquentes (avec la distribution précédente assez dépassée). <br><b>Matthew :</b> Pour le moment, l'équilibre est à mon avis mauvais, et je pense que des cycles de publication plus courts amélioreraient cela. <p><b>Ben :</b> Je considère la structure des dépôts de paquets comme une technologie activante (pour créer un néologisme adapté, même si je déteste cela :)), et il en résultera des publications plus rapides. <br><b>Ben :</b> Pour y arriver, cela dépendra plus du juste milieu, à savoir où nous décidons de comment tirer partie de cette nouvelle structure. Comme la plupart d'entre vous le sait, Gui a décidé que les dépôts de paquets étaient la solution, et Jason et moi avons essayé de l'implémenter en utilisant LDAP comme support principal... donc les choses progressent (doucement, car la publication actuelle demande du temps). Lorsque les dépôts seront en place, nous aurons besoin d'idées et du travail d'autres développeurs pour l'améliorer. <p><b>Wichert :</b> Comme l'a dit Ben, le travail est en cours sur les dépôts de paquets, qui semblent vraiment être un bonne idée pour faciliter tout ce qui est lié au processus de publication. Notre gestionnaire de publication a déjà affirmé vouloir geler plus rapidement (si je me souviens bien, il a parlé de 3 mois après la publication), ce qui devrait également aider. Espérons que la combinaison des possibilités et de la flexibilité des dépôts de paquets avec un cycle de publication plus rapide devrait produire une distribution meilleure et plus à jour. Cependant, nous ne devrions pas nous concentrer uniquement sur l'empaquetage et les systèmes de paquets... <br><b>Wichert :</b> Nous devons également nous concentrer sur d'autres domaines comme une assurance qualité active et la documentation. Celles-ci deviennent de plus en plus importantes, en particulier avec notre base d'utilisateurs croissante. <h2>Dernières réflexions</h2> <p><b>Rob :</b> OK... maintenant, avec l'autorisation de nos candidats, nous allons faire une minute de résumé des objectifs et opinions de chacun. Je vais juste choisir quelqu'un pour commencer, pour le moment il est difficile de voir si nous avons créé un motif :) <p><b>Ben :</b> J'espère que j'ai bien montré que j'étais plus intéressé par les sujets concernant le travail interne de Debian, en comparaison avec les vues des autres... Je dit cela car je suis convaincu que vous ne pouvez pas changer l'opinion que les autres ont de vous en les changeant, mais en changeant ce que vous faites... <br><b>Ben :</b> Si nous nous concentrons sur notre travail... cela va payer et d'autres reconnaîtront ce que nous avons et ce que nous ferons. <p><b>Wichert :</b> Au cours de ces dernières années, j'ai appris beaucoup sur le fonctionnement de Debian, et sur les endroits qui ont besoin d'améliorations. <br><b>Wichert :</b> Hum. <br><b>Wichert :</b> C'est difficile :) <br><b>Wichert :</b> Je pense que nous devrons réaliser que cela ne se résume pas à la création des paquets. Et j'aimerais aider Debian à s'étendre dans d'autres domaines. <br><b>Wichert :</b> Nous avons déjà beaucoup de personnes travaillant sur les paquets et les questions techniques, et il semble que cela marche assez bien. <p><b>Matthew :</b> Je veux garder Debian la meilleure possible au niveau technique. Pour le moment, cela signifie gérer la croissance importante de Debian (ce qui est une bonne chose, mais amène ses propres problèmes). La communication semble être le point clé, et encourager les développeurs à prendre en compte des choses comme l'assurance qualité et la documentation autant que l'empaquetage. J'ai de l'expérience dans la gestion de groupes disparates pour qu'ils puissent travailler correctement ensemble. <br><b>Matthew :</b> En particulier sachant que certaines parties de Debian commencent à être gérées par des groupes totalement indépendants des autres parties (si cela a du sens). <br><b>Matthew :</b> En dehors de cela, puis-je juste encourager tout le monde à voter ? La participation semble toujours assez faible pour l'élection du chef de projet.
Attachment:
pgpAHUDR6NLpJ.pgp
Description: PGP signature