Étant moi aussi mauvais en français, je me permet de lui adresser (quand même) mes félicitations dans notre langue natale :
Houé Greaux ! Tas gars-nié !
Sur quel programme a-t'il été élu ? Va-t'il enfin faire passer sa distribution à un vrai système de paquet comme RPM ? Va-t'il imposer Unity comme DE par défaut ? Va-t'il pousser un vrai éditeur de texte comme Emacs comme éditeur par défaut ? Firefox va-t'il se retrouver dans Debian ? Les releases sortiront-elles enfin sans 42 ans de retard ? Systemd sera-t'il l'init par défaut ? Darwin va-t'il apparaître comme noyau de prédilection ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
blague à part, la mise en paquet debian se faisant en résumé dans un slide de 79 événements, ça serait pas mal de passer à un système comme les PKGBUILD, où c'est vraiment archi simple de contribuer à faire des paquets.
Réaliser des paquets binaires sous debian, rien que ça déjà ça me gave, mais des paquets sources n'en parlons pas tellement c'est fastidieux.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
Ayant eu à faire les 2, je ne peux qu'approuver. Créer un paquet pour Arch est d'une simplicité enfantine à coté de celle d'un paquet Debian.
J'irai même plus loin que toi: plutot que de seulement s'inspirer, pourquoi ne pas utiliser directement les PKGBUILD pour Debian et partager le même format pour les 2 distribs ?
Posté par Adrien .
Évalué à 6.
Dernière modification le 15 avril 2013 à 15:36.
perso c'est pas tellement l'empaquetage qui me prend du temps, mais tout le reste : vérifier que les dev n'ont pas eu la mauvaise idée d'inclure des bibliothèques dans leur machin, vérifier que les licences sont bien libres, gérer les casses lors des transition, gérer les bugs des utilisateurs, etc. À ça on peut rajouter le respect des politiques de Debian, ce qui prende un peu temps.
Au final, faire un paquet debian, ça va très vite… quand les dev amont font bien leur boulot… mais là, je m'avance pour vendredi.
J'ai déjà essayé de faire un paquet debian mais je ne suis jamais arrivé au bout. Pour le premier, un logiciel en Java, il y a avait plein de dépendance non incluses dans Debian. Pour le deuxième, un logiciel Qt, je n'ai pas trouvé de méthode propre pour appeler qmake et faire le paquet. Du coup, à part copier-coller les lignes de la documentation qui ne marchent que pour peu de paquets au final, je ne suis jamais arrivé à rien. (je n'ai jamais fait de paquet pour Arch non plus, n'étant pas resté assez longtemps sur cette distro).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
$ cat ~/codaz/QPdfPresenterConsole/debian/rules
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/cmake.mk
# Add here any variable or target overrides you need.
Et je vois un /usr/share/cdbs/1/class/qmake.mk, donc il doit être possible de faire aussi court.
Posté par claudex .
Évalué à 4.
Dernière modification le 15 avril 2013 à 16:25.
Merci je note. Mais ce n'est pas facile de trouver ce genre d'infos (ou alors, je cherche mal). Je trouve que ça devrait se trouver dans la documentation pour faire un paquet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Effectivement un package fait avec dh peut etre relativement simple. Le probleme à mon avis c'est pas que les outils soient mauvais, mais c'est qu'il y en a trop.
Tout le monde utilise un gestionnaire de version different, tout le monde utilise un "packaging helper" different, tout le monde utilise un format de package et un systeme de patches different …
Et c'est pareil pour le reste. Il y a plusieurs facons de builder un package source, plusieurs outils pour uploaded un paquet, etc …
Je suis d'accord, le packaging Debian me parait excessivement compliqué. Plusieurs formats de paquets supportés, plusieurs outils pour faire les memes choses mais de facon legerement differentes, et de facon generale toujours plusieurs facons de faire la meme chose. L'avantage c'est que tout le monde peut faire du packaging à sa facon, mais tout ca finit par ressembler à une grosse usine à gaz.
J'espère qu'il va vraiment défraîchir le bazarre, car j'ai tenté plusieurs fois, j'ai lu les 2 derniers cahiers de l'admin, les tutos, un atelier au FOSDEM, ce qui en ressort: c'est louuuuurd!
L'organisation interne est vraiment une barrière même si ça marche ou est même souvent montrée en qualité.
J'utilise Debian tous les jours, et bien je préfère malheureusement compiler depuis les sources et maintenir un "arbre" le logiciels sur le côté.
C'est marrant il y a eu la discussion il y a une semaine ou deux dans l'équipe Debian KDE : faut-il avoir un système similaire aux PPA pour le packaging KDE ? Quleques uns étaient bien motivé par ça, mais les autres bof. Perso je ne suis pas sûr que ça soit la solution miracle pour attirer du monde vers le packaging Debian, les équipes permettent déjà d'accueillir des nouveaux assez facilement, pour peu que l'équipe soit ouverte.
Quand à testing en rolling release, là aussi il y a sans doute une incompréhension : il est souvent reproché au freeze que testing n'évolue plus… mais c'est bien le but. Si cette phase est trop longue, c'est avant tout parce qu'il n'y a pas assez de gens pour corriger les bugs bloquants… mettre testing en rolling release ne changera rien à ça, au contraire, c'est prendre le risque que les dev se concentre avant tout sur testing et délaisse stable.
Pour ma part ce que je reproche au freeze, c'est de bloquer l'unstable, pas la testing. Par exemple la Debian «rolling» actuelle propose un Gnome 3.4, c'est à dire plus d'un an de «retard» sur la 3.8.
Alors oui, on peut piocher ce dont on a besoin dans experimental, le problème étant qu'il y a beaucoup d'experimental dedans ;)
Bref, la situation me semble loin d'être idéale. J'aurai aimé que ma sid installe toute seule la dernière version de Firefox/Iceweasel considérée stable par Mozilla (exactement comme elle le faisait avant le freeze), qu'elle m'interdise l'installation de Gnome 3.6 parce qu'elle était dans "experimental" à raison, mais par contre qu'elle me propose l'installation de Gnome 3.8, "parce que ça marche".
Bien sûr ce ne sont que des exemples, et je me débrouille avec du pinning, mais c'est loin d'être des plus pratique… et j'en suis à utiliser des snapshots (btrfs) avant certains upgrades, suite à une quelques mauvaises expériences.
En tous cas pour mes desktops j'aurais adoré avoir une Debian «Cut», dont je n'aurais pas à me soucier, et qui choisirait judicieusement les paquets dans testing/unstable/experimental en fonction de ce qui marche aujourd'hui et non pas en fonction de ce qu'on voudra dans la release stable.
J'aurai aimé que ma sid installe toute seule la dernière version de Firefox/Iceweasel considérée stable par Mozilla (exactement comme elle le faisait avant le freeze), qu'elle m'interdise l'installation de Gnome 3.6 parce qu'elle était dans "experimental" à raison, mais par contre qu'elle me propose l'installation de Gnome 3.8, "parce que ça marche".
On en revient toujours à la même chose :
– si le freeze est trop long, il faut plus de gens pour corriger les bugs. Avec un freeze de quelques mois seulement, ça passerait bien mieux.
– ensuite tu veux avoir le dernier firefox mais pas le dernier gnome… La effectivement avoir un dépot par paquet peut être intéressant pour avoir les toutes dernières nouveautés. Perso je ne suis pas persuadé que c'est judicieux pour Debian, si le retard des paquets n'est pas trop grand. Quand on commence à avoir plusieurs version de retards sur upstream, là effectivement d'un point de vue utilisateur ça peut être gênant.
Clairement le freeze est vraiment long en ce moment, et ça fout un peu la merde : certains paquets sont déjà vieux, les nouvelles versions attendent avec impatience que la situation se débloque, les utilisateurs sont aussi en attentes, que ce soit pour la nouvelles stables ou testing… Bref, il faut des périodes de freeze moins longues… et donc soit diminuer le nombre de bugs critiques (ce qui ne va pas dans le sens de la qualité) soit augmenter le nombre de gens impliqués…
S'il y a tant besoin d'aide, je pense qu'il serait judicieux de simplifier les procédures : je ne pense pas être un manche, je gère quelques centaines de serveurs et une poignée de postes, tous sous Debian, et pourtant contribuer me semble toujours aussi long et fastidieux.
Comment puis-je contribuer efficacement, sur les paquets que j'utilise au quotidien, sans qu'on m'invite à aller me perdre dans les méandres du manuel du développeur Debian ?
Comment puis-je contribuer efficacement, sur les paquets que j'utilise au quotidien, sans qu'on m'invite à aller me perdre dans les méandres du manuel du développeur Debian ?
Je suis d'accord pour dire que le manuel du développeur Debian est comme un paté lorrain : ça tient au corps. Ubuntu a fait beaucoup sur la documentation, l'explication pour les débutants et c'est très très bien, Debian ferait bien de s'y inspirer. Par contre il me semble normal de bien comprendre le pourquoi de la distribution, quels sont les buts, comment c'est organisé, etc. C'est un peu chiant, mais à mon avis nécessaire.
Pour contribuer, le mieux est je pense que prendre contact avec les équipes qui s'occupent des paquets qui t'intéresse, par exemple sur IRC ou par email et voir avec elles. Chaque équipe à son organisation, à voir au cas par cas. Une autre façon de faire est de s'occuper des bugs : les transmettre aux développeurs si nécessaire, gérer les trop vieux bugs, fermé ceux qui sont corrigés, etc. Une dernière approche pourrait peut-être consister en se focaliser sur les bugs « release critical », qui empêche la nouvelle version de sortir. C'est plus technique et transverse aux équipes, mais il y a sans doute moyen de faire avancer les choses de ce point de vue-là.
Et si tu n'est pas trop codeur, tu peux aussi contribuer au wiki Debian, un peu pauvre. Perso j'ai toujours trouvé le wiki français d'Ubuntu vraiment très très bien fait, je regrette vraiment qu'il n'y ait pas l'équivalent pour Debian. Typiquement avoir des pages simples sur comment contribuer à Debian, comment faire son paquet, etc.
Et si tu n'est pas trop codeur, tu peux aussi contribuer au wiki Debian, un peu pauvre. Perso j'ai toujours trouvé le wiki français d'Ubuntu vraiment très très bien fait, je regrette vraiment qu'il n'y ait pas l'équivalent pour Debian.
wiki.debian.org ne le deviendra jamais. 90% de ce qui est sur doc.ubuntu-fr.org serait refusé car n'ayant pas sa place (devrait être remonté dans la documentation upstream).
Typiquement avoir des pages simples sur comment contribuer à Debian, comment faire son paquet, etc.
Oui, mais contribuer à ce wiki ne demande presque rien. Il faut créer un compte et commencer à éditer des pages. C'est à peine moins ouvert que wikipedia (où il n'est pas nécessaire de créer un compte).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Passer Testing comme une distro rolling-release, l'idée n'est pas nouvelle avec le programme:
C'est l'idée de la Constantly Usable Testing (Debian CUT).
Mais quand on va sur la page, c'est désespérant tellement on a l'impression que ça ne change rien au schmilblick:
Le dernier snapshot est d'août 2012, et en gras en haut de la page, on peut lire:
"Paused until Debian Wheezy is released."
Citons l'exemple d'une appli qui, si elle n'est pas une appli phare, n'en est pas moins plutôt populaire: le navigateur rekonq.
Testing 0.9.2-1
Experimental 1.1-1
Liste des versions amont depuis la 1.1:
Version Date de sortie
1.1 08/2012
2.0alpha 11/2012
2.0stable 12/2012
2.1 01/2013
2.2 02/2013
Et on ne peut pas blâmer les mainteneurs: ils ont les 2 mains prises dans Wheezy.
Questions:
-Pourquoi les outils pour créer les paquets ne seraient pas assez simples et puissants pour que l'amont puisse créer un paquet "vanilla" sans difficulté? Au lieu de créer le paquet, les mainteneurs ajusteraient une fois un fichier de config qui dit quelles modifs sont à faire. Pas les patches sur le code, mais des trucs cons genre emplacement des fichiers, suffixes du nom de paquet, etc.
Comme ça, à chaque nouvelle version qui n'apporte pas une révolution, les développeurs n'auraient qu'un bouton à presser pour mettre à jour un dépôt experimental à eux.
-Je n'ai aucun doute sur l'excellence du niveau du contrôle qualité de Debian, mais pourquoi est-ce qu'il doit prendre autant de temps?
À un moment, il va falloir accepter de tailler dans le lard: un paquet trop long à être corrigé doit se faire jeter, point barre. Si ça choque des utilisateurs, ils peuvent rémunérer des développeurs Debian pour y consacrer leur temps.
Debian sort quand elle est prête: surtout ne pas changer ce crédo. Mais: ne pas l'appliquer aux correctifs de paquets!
Existe-t-il une date limite aux corrections de bugs critiques spécifique en période de gel? Si non, il faut l'instaurer. Après quoi, si le délai est dû à un manque d'attention, le paquet est déclaré orphelin. En période de gel, le délai devrait être 1 semaine sans activité significative, voire moins! L'équipe en charge de la version se charge de traquer les retardataires et de prendre les décisions difficiles (ex:retirer un paquet à son développeur jusqu'à la sortie de la stable).
Pour parer aux problème que cela inclue, il faudrait peut-être une nouvelle catégorie de paquets en plus de main, contrib, non-free, pour tous ces paquets qui sont arrivés trop tard mais qui "auraient pu le faire", un "noQAcert", qui devra être aussi stable que les stables et pour lequel une fenêtre de quelques mois sera ouverte après la sortie officielle d'une version.
Voilà! C'étaient mes 2 balles en tant qu'utilisateur.
# Langue natale
Posté par Julien_J06 . Évalué à 10.
Étant Nancéien d'origine, je me permet de lui adresser mes félicitations dans notre langue natale :
Wué Grow ! T'as gâgnêï !
Julien_c'est_bien (y'a pas que Seb)
[^] # Re: Langue natale
Posté par cosmocat . Évalué à 6.
Étant moi aussi mauvais en français, je me permet de lui adresser (quand même) mes félicitations dans notre langue
natale:Houé Greaux ! Tas gars-nié !
=>[]
[^] # Re: Langue natale
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Étant parisien, je me permets de lui adresser mes félicitations dans notre langue normale :
[^] # Re: Langue natale
Posté par Anonyme . Évalué à 1.
Je crois que tu as oublié les « eeeennnt » à la fin de chaque mot. Un peu comme « c'est contre naturrreeeent », m'voyez ?
[^] # Re: Langue natale
Posté par wolowizard . Évalué à 10.
Etant sur linuxfr, je me permets de lui adresser ces termes:
"Tu aurais pu passer sur Arch"
----> []
# Demandez le programme !
Posté par claudex . Évalué à 10.
Sur quel programme a-t'il été élu ? Va-t'il enfin faire passer sa distribution à un vrai système de paquet comme RPM ? Va-t'il imposer Unity comme DE par défaut ? Va-t'il pousser un vrai éditeur de texte comme Emacs comme éditeur par défaut ? Firefox va-t'il se retrouver dans Debian ? Les releases sortiront-elles enfin sans 42 ans de retard ? Systemd sera-t'il l'init par défaut ? Darwin va-t'il apparaître comme noyau de prédilection ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Demandez le programme !
Posté par Mali (site web personnel) . Évalué à 6.
Rien de tout cela, mais bien plus que cela :)
Programme de lucas
[^] # Re: Demandez le programme !
Posté par fravashyo . Évalué à 9.
blague à part, la mise en paquet debian se faisant en résumé dans un slide de 79 événements, ça serait pas mal de passer à un système comme les PKGBUILD, où c'est vraiment archi simple de contribuer à faire des paquets.
Réaliser des paquets binaires sous debian, rien que ça déjà ça me gave, mais des paquets sources n'en parlons pas tellement c'est fastidieux.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Demandez le programme !
Posté par flagos . Évalué à 8.
Ayant eu à faire les 2, je ne peux qu'approuver. Créer un paquet pour Arch est d'une simplicité enfantine à coté de celle d'un paquet Debian.
J'irai même plus loin que toi: plutot que de seulement s'inspirer, pourquoi ne pas utiliser directement les PKGBUILD pour Debian et partager le même format pour les 2 distribs ?
[^] # Re: Demandez le programme !
Posté par Mali (site web personnel) . Évalué à 8.
Pour avoir aussi expérimenté les deux, je ne peux que pertinenter !
[^] # Re: Demandez le programme !
Posté par Adrien . Évalué à 6. Dernière modification le 15 avril 2013 à 15:36.
perso c'est pas tellement l'empaquetage qui me prend du temps, mais tout le reste : vérifier que les dev n'ont pas eu la mauvaise idée d'inclure des bibliothèques dans leur machin, vérifier que les licences sont bien libres, gérer les casses lors des transition, gérer les bugs des utilisateurs, etc. À ça on peut rajouter le respect des politiques de Debian, ce qui prende un peu temps.
Au final, faire un paquet debian, ça va très vite… quand les dev amont font bien leur boulot… mais là, je m'avance pour vendredi.
EDIT: je n'ai jamais fait de paquet Arch..
[^] # Re: Demandez le programme !
Posté par claudex . Évalué à 5.
J'ai déjà essayé de faire un paquet debian mais je ne suis jamais arrivé au bout. Pour le premier, un logiciel en Java, il y a avait plein de dépendance non incluses dans Debian. Pour le deuxième, un logiciel Qt, je n'ai pas trouvé de méthode propre pour appeler qmake et faire le paquet. Du coup, à part copier-coller les lignes de la documentation qui ne marchent que pour peu de paquets au final, je ne suis jamais arrivé à rien. (je n'ai jamais fait de paquet pour Arch non plus, n'étant pas resté assez longtemps sur cette distro).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Demandez le programme !
Posté par Alexandre . Évalué à 2.
Avec CMake,
Et je vois un /usr/share/cdbs/1/class/qmake.mk, donc il doit être possible de faire aussi court.
[^] # Re: Demandez le programme !
Posté par claudex . Évalué à 4. Dernière modification le 15 avril 2013 à 16:25.
Merci je note. Mais ce n'est pas facile de trouver ce genre d'infos (ou alors, je cherche mal). Je trouve que ça devrait se trouver dans la documentation pour faire un paquet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Demandez le programme !
Posté par Anonyme . Évalué à 3.
Effectivement un package fait avec dh peut etre relativement simple. Le probleme à mon avis c'est pas que les outils soient mauvais, mais c'est qu'il y en a trop.
On peut le voir la dessus :
http://www.lucas-nussbaum.net/blog/?p=751
Tout le monde utilise un gestionnaire de version different, tout le monde utilise un "packaging helper" different, tout le monde utilise un format de package et un systeme de patches different …
Et c'est pareil pour le reste. Il y a plusieurs facons de builder un package source, plusieurs outils pour uploaded un paquet, etc …
[^] # Re: Demandez le programme !
Posté par Anonyme . Évalué à 8.
Je suis d'accord, le packaging Debian me parait excessivement compliqué. Plusieurs formats de paquets supportés, plusieurs outils pour faire les memes choses mais de facon legerement differentes, et de facon generale toujours plusieurs facons de faire la meme chose. L'avantage c'est que tout le monde peut faire du packaging à sa facon, mais tout ca finit par ressembler à une grosse usine à gaz.
[^] # Re: Demandez le programme !
Posté par Mali (site web personnel) . Évalué à 5.
Et du coup quand tu demandes de l'aide, personne ne répond la même chose, car chaque DD à sa vision de comment il faudrait faire !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Demandez le programme !
Posté par Mme Michu-cide . Évalué à 2.
J'espère qu'il va vraiment défraîchir le bazarre, car j'ai tenté plusieurs fois, j'ai lu les 2 derniers cahiers de l'admin, les tutos, un atelier au FOSDEM, ce qui en ressort: c'est louuuuurd!
L'organisation interne est vraiment une barrière même si ça marche ou est même souvent montrée en qualité.
J'utilise Debian tous les jours, et bien je préfère malheureusement compiler depuis les sources et maintenir un "arbre" le logiciels sur le côté.
[^] # Re: Demandez le programme !
Posté par Adrien . Évalué à 5.
C'est marrant il y a eu la discussion il y a une semaine ou deux dans l'équipe Debian KDE : faut-il avoir un système similaire aux PPA pour le packaging KDE ? Quleques uns étaient bien motivé par ça, mais les autres bof. Perso je ne suis pas sûr que ça soit la solution miracle pour attirer du monde vers le packaging Debian, les équipes permettent déjà d'accueillir des nouveaux assez facilement, pour peu que l'équipe soit ouverte.
Quand à testing en rolling release, là aussi il y a sans doute une incompréhension : il est souvent reproché au freeze que testing n'évolue plus… mais c'est bien le but. Si cette phase est trop longue, c'est avant tout parce qu'il n'y a pas assez de gens pour corriger les bugs bloquants… mettre testing en rolling release ne changera rien à ça, au contraire, c'est prendre le risque que les dev se concentre avant tout sur testing et délaisse stable.
[^] # Re: Demandez le programme !
Posté par Kioob (site web personnel) . Évalué à 2.
Pour ma part ce que je reproche au freeze, c'est de bloquer l'unstable, pas la testing. Par exemple la Debian «rolling» actuelle propose un Gnome 3.4, c'est à dire plus d'un an de «retard» sur la 3.8.
Alors oui, on peut piocher ce dont on a besoin dans experimental, le problème étant qu'il y a beaucoup d'experimental dedans ;)
Bref, la situation me semble loin d'être idéale. J'aurai aimé que ma sid installe toute seule la dernière version de Firefox/Iceweasel considérée stable par Mozilla (exactement comme elle le faisait avant le freeze), qu'elle m'interdise l'installation de Gnome 3.6 parce qu'elle était dans "experimental" à raison, mais par contre qu'elle me propose l'installation de Gnome 3.8, "parce que ça marche".
Bien sûr ce ne sont que des exemples, et je me débrouille avec du pinning, mais c'est loin d'être des plus pratique… et j'en suis à utiliser des snapshots (btrfs) avant certains upgrades, suite à une quelques mauvaises expériences.
En tous cas pour mes desktops j'aurais adoré avoir une Debian «Cut», dont je n'aurais pas à me soucier, et qui choisirait judicieusement les paquets dans testing/unstable/experimental en fonction de ce qui marche aujourd'hui et non pas en fonction de ce qu'on voudra dans la release stable.
alf.life
[^] # Re: Demandez le programme !
Posté par Adrien . Évalué à 6.
On en revient toujours à la même chose :
– si le freeze est trop long, il faut plus de gens pour corriger les bugs. Avec un freeze de quelques mois seulement, ça passerait bien mieux.
– ensuite tu veux avoir le dernier firefox mais pas le dernier gnome… La effectivement avoir un dépot par paquet peut être intéressant pour avoir les toutes dernières nouveautés. Perso je ne suis pas persuadé que c'est judicieux pour Debian, si le retard des paquets n'est pas trop grand. Quand on commence à avoir plusieurs version de retards sur upstream, là effectivement d'un point de vue utilisateur ça peut être gênant.
Clairement le freeze est vraiment long en ce moment, et ça fout un peu la merde : certains paquets sont déjà vieux, les nouvelles versions attendent avec impatience que la situation se débloque, les utilisateurs sont aussi en attentes, que ce soit pour la nouvelles stables ou testing… Bref, il faut des périodes de freeze moins longues… et donc soit diminuer le nombre de bugs critiques (ce qui ne va pas dans le sens de la qualité) soit augmenter le nombre de gens impliqués…
[^] # Re: Demandez le programme !
Posté par Kioob (site web personnel) . Évalué à 6.
S'il y a tant besoin d'aide, je pense qu'il serait judicieux de simplifier les procédures : je ne pense pas être un manche, je gère quelques centaines de serveurs et une poignée de postes, tous sous Debian, et pourtant contribuer me semble toujours aussi long et fastidieux.
Comment puis-je contribuer efficacement, sur les paquets que j'utilise au quotidien, sans qu'on m'invite à aller me perdre dans les méandres du manuel du développeur Debian ?
alf.life
[^] # Re: Demandez le programme !
Posté par Adrien . Évalué à 2.
Je suis d'accord pour dire que le manuel du développeur Debian est comme un paté lorrain : ça tient au corps. Ubuntu a fait beaucoup sur la documentation, l'explication pour les débutants et c'est très très bien, Debian ferait bien de s'y inspirer. Par contre il me semble normal de bien comprendre le pourquoi de la distribution, quels sont les buts, comment c'est organisé, etc. C'est un peu chiant, mais à mon avis nécessaire.
Pour contribuer, le mieux est je pense que prendre contact avec les équipes qui s'occupent des paquets qui t'intéresse, par exemple sur IRC ou par email et voir avec elles. Chaque équipe à son organisation, à voir au cas par cas. Une autre façon de faire est de s'occuper des bugs : les transmettre aux développeurs si nécessaire, gérer les trop vieux bugs, fermé ceux qui sont corrigés, etc. Une dernière approche pourrait peut-être consister en se focaliser sur les bugs « release critical », qui empêche la nouvelle version de sortir. C'est plus technique et transverse aux équipes, mais il y a sans doute moyen de faire avancer les choses de ce point de vue-là.
Et si tu n'est pas trop codeur, tu peux aussi contribuer au wiki Debian, un peu pauvre. Perso j'ai toujours trouvé le wiki français d'Ubuntu vraiment très très bien fait, je regrette vraiment qu'il n'y ait pas l'équivalent pour Debian. Typiquement avoir des pages simples sur comment contribuer à Debian, comment faire son paquet, etc.
[^] # Re: Demandez le programme !
Posté par barmic . Évalué à 3.
Tu oublie l'un des points d'entré important pour contribuer : http://mentors.debian.net/
wiki.debian.org ne le deviendra jamais. 90% de ce qui est sur doc.ubuntu-fr.org serait refusé car n'ayant pas sa place (devrait être remonté dans la documentation upstream).
Oui, mais contribuer à ce wiki ne demande presque rien. Il faut créer un compte et commencer à éditer des pages. C'est à peine moins ouvert que wikipedia (où il n'est pas nécessaire de créer un compte).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Demandez le programme !
Posté par Maclag . Évalué à 5.
Passer Testing comme une distro rolling-release, l'idée n'est pas nouvelle avec le programme:
C'est l'idée de la Constantly Usable Testing (Debian CUT).
Mais quand on va sur la page, c'est désespérant tellement on a l'impression que ça ne change rien au schmilblick:
Le dernier snapshot est d'août 2012, et en gras en haut de la page, on peut lire:
"Paused until Debian Wheezy is released."
Citons l'exemple d'une appli qui, si elle n'est pas une appli phare, n'en est pas moins plutôt populaire: le navigateur rekonq.
Testing 0.9.2-1
Experimental 1.1-1
Liste des versions amont depuis la 1.1:
Version Date de sortie
1.1 08/2012
2.0alpha 11/2012
2.0stable 12/2012
2.1 01/2013
2.2 02/2013
Et on ne peut pas blâmer les mainteneurs: ils ont les 2 mains prises dans Wheezy.
Questions:
-Pourquoi les outils pour créer les paquets ne seraient pas assez simples et puissants pour que l'amont puisse créer un paquet "vanilla" sans difficulté? Au lieu de créer le paquet, les mainteneurs ajusteraient une fois un fichier de config qui dit quelles modifs sont à faire. Pas les patches sur le code, mais des trucs cons genre emplacement des fichiers, suffixes du nom de paquet, etc.
Comme ça, à chaque nouvelle version qui n'apporte pas une révolution, les développeurs n'auraient qu'un bouton à presser pour mettre à jour un dépôt experimental à eux.
-Je n'ai aucun doute sur l'excellence du niveau du contrôle qualité de Debian, mais pourquoi est-ce qu'il doit prendre autant de temps?
À un moment, il va falloir accepter de tailler dans le lard: un paquet trop long à être corrigé doit se faire jeter, point barre. Si ça choque des utilisateurs, ils peuvent rémunérer des développeurs Debian pour y consacrer leur temps.
Debian sort quand elle est prête: surtout ne pas changer ce crédo. Mais: ne pas l'appliquer aux correctifs de paquets!
Existe-t-il une date limite aux corrections de bugs critiques spécifique en période de gel? Si non, il faut l'instaurer. Après quoi, si le délai est dû à un manque d'attention, le paquet est déclaré orphelin. En période de gel, le délai devrait être 1 semaine sans activité significative, voire moins! L'équipe en charge de la version se charge de traquer les retardataires et de prendre les décisions difficiles (ex:retirer un paquet à son développeur jusqu'à la sortie de la stable).
Pour parer aux problème que cela inclue, il faudrait peut-être une nouvelle catégorie de paquets en plus de main, contrib, non-free, pour tous ces paquets qui sont arrivés trop tard mais qui "auraient pu le faire", un "noQAcert", qui devra être aussi stable que les stables et pour lequel une fenêtre de quelques mois sera ouverte après la sortie officielle d'une version.
Voilà! C'étaient mes 2 balles en tant qu'utilisateur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.