On Mon, Jun 23, 2003 at 01:58:24PM +0100, Yves Rutschle wrote: > On Mon, Jun 23, 2003 at 01:58:02PM +0200, Sven Luther wrote: > > Et je supppose que par categorie tu dis ceux qui ne veulent pas utiliser > > unstable, et ne sont pas satisfait avec stable, pour une raison ou une > > autre. Est-ce exacte ? Pourquoi ne sont-il pas satisfait de stable ? > > C'est la version releaser officielle, et la seule chose que debian est > > capable de distribuer de maniere stable en ce moment. > > A un moment dans le thread, quelqu'un faisait remarquer que > seuls les DD avaient voie au chapitre pour faire des > d�cisions "strat�giques", ce qui est un probl�me quand on > veut s'adresser aux utilisateurs... > > Donc, pour r�sumer la situation: > > - Erwan, Georges, et d'autres, pensent que tout paquet > devrait �tre compil� pour les d�pendances les plus vieilles > possibles. Si Perl 5.6.0 peut techniquement tourner sur Bo, > le paquet ne devrait d�pendre que de Bo. Si Hevea 3.6 a > besoin de Ocaml 3.6, bien s�r il faudra upgrader Ocaml. > Ceci permettrait d'avoir une distrib "stable" moins > d�pass�e, o� les nouvelles versions entreraient plus > rapidement. En fait, la notion m�me de stable devient floue, > puisque les versions des paquets pourraient y changer. (Il > me semble que c'est plus ou moins le mod�le adopt� par > Gentoo... mais je ne connais pas suffisament).
C'est ce qu'aurrai du etre la distrib testing, elle l'est en partie, mais il y a encore des problemes, qui seront sans doutes resolu par la suite, apres la release de sarge. > - La position officielle de Debian (que j'ai finalement > r�ussi � comprendre, merci Sven) est que les DD travaillent > "� la pointe", on remet tout � jour constament, et un jour > on converge pour tout stabiliser et fixer les versions qu'on > utilise. Du coup, tous les DD ont utilis� la nouvelle libc, > le nouveau gcc, etc, et donc l'ensemble est plus test� > (avantage par rapport � la m�thode pr�c�dente). Un fois tout > �a fix�, on v�rifie que le passage stable->testing marche > correctement (et on ne v�rifie pas �a avant, si j'ai tout Oui, c'est fait assez a la fin du cycle de release, le faire avant representerai une duplication d'effort non justifiable. > compris) et on fait une nouvelle stable. "stable" est donc > plus test�, mais reste alors fix�e pour les x ann�es de > developpement de la prochaine version. Oui, il y a effectivement une divergence de but, et l'ideal serait d'obtenir les deux, et c'est probablement faissable, la divergence reelle est dans les moyens de l'obtenir, et dans l'ordre des priorites Moi, et c'est mon avis personnel, est que la meilleure solution serait de rapprocher les dates des releases debian, avec une release par ans, le probleme de stable qu n'est plus assez nouveau ne se posera plus alors. > A priori et � mon avis, les deux positions se tiennent. Par > contre: > > > 4 Nos priorit�s sont nos utilisateurs et les logiciels libres > > > > Les besoins de nos utilisateurs et de la communaut� des logiciels libres > > nous guideront. Nous placerons leurs int�r�ts en t�te de nos priorit�s. > > Quel est le vrai inter�t des utilisateurs? Car pour le > moment, il semble que les utilisateurs (Erwan et Georges, et > moi aussi un peu) ne sont en fait pas d'accord avec la fa�on > dont Debian d�veloppe. Bon, il faut savoir que le chapitre en question etait surtout la pour donner un equilibre entre le besoin des utilisateur qui necessitait des logiciels commerciaux et le fait de n'accepter que des logiciels libres. C'est comme cela que je lis ce paragraphe, mais cela predate mon epoque, bien sur. Ceci dis, tu a bien raison, mais ce que Georges et Erwan propose c'est que les DDs ajoutent une charge de plus a leur implication dans debian, pour satisfaire un somme toute petit groupe d'utilisateur, qui se croient assez competent pour critiquer et juger de la meilleure maniere de faire pour debian, mais ne jugent pas cela assez important pour y devouer leur propre temps. D'un autre cote, il sont assez competent pour suivre soit testing soit unstable, mais ne le font pas. Moi, je sais de quel quantite de temps libre je dispose pour s'occuper de debian, et ce que je peut realiser avec cela, j'ai aussi un certain apercu de l'etat des choses, et donc je juge correct la politique de debian qui est de mettre la priorite a la prochaine release. C'est notre choix, et nous mettons toute notre energie pour l'accomplir. Maintenant, d'autre trouvent que ce n'est pas le bon choix, mais est-ce qu'il sont pret a donner d'eux meme pour soutenir leur choix, pas d'apres ce que je vois. > Dans un environement de logiciel libre, o� tous les > composants �voluent ind�pendemment de Debian, est-il > raisonnable pour Debian de vouloir faire des "releases" au > m�me sens que les distributeurs commerciaux (RedHat ou > Microsoft)? Oui, mais debian est aussi pour des utilisateurs de serveurs, et d'autre machine au cycle de release plus lent. C'est surtout a eux que s'adresse les mise a jour de securite d'ailleurs. Et c'est a eux que s'adressent les releases evidement, et aussi a tous les utilisateurs qui ont besoin d'une distribution de qualite, sans forcement toutes les dernieres versions de toutes les choses. > Et, quels utilisateurs ont �t� interrog�s pour arriver � la > conclusion qu'il fallait des releases bien d�finie, ou bien > ce choix fut-il fait par les DD pour le bien des > utilisateurs? Mmm, je pense que c'est surtout une raison historique, et comme les DDs etait les premiers utilisateurs, ont a quand meme une idee de ce qu'il en est, moi meme, je pense que c'est une bonne chose, et l'infrastructure actuelle de debian ne permet pas de faire une version continuellement a jour. C'est ce qu'aurrai du etre testing, et cela a pas marche, mais peut-etre une autre fois. Mais bien sur, si tu est pret a faire une enquete serieuse sur la question, libre a toi, et si le resultat est reellement different de ce que debian semble penser, cela aura un grand retentissement, bien sur. > > Je crois que ce point parle uniquement des logiciels commerciaux, mais > > comme dis, rien n'empeche une tierce partie de faire des backport de > > qualite, et de les distribuer. Le seul probleme, c'est lorsque les > > backport sont mal fait, et que l'on voit apparaitre des bugreport dans > > le BTS qui ne corresponde pas aux package debian, alors cela coince. > > C'est clair, le BTS ne devrait �tre utilis� que pour les > paquets officiels. Oui, le BTS, et qu'en est-il des mailing listes debian-user et co ? Quand on voit les gens qui ont des problemes avec les drivers proprietaires nvidia par exemple ? > > Mais a nouveau, rien ne t'empeche toi et Mariano de travailler sur des > > backports propres, et meme de devenir DD dans le but explicite de > > maintenir une distribution de backports, mais cela ne vous interesse > > pas. > > Or donc, c'est bien l� l'argument de Georges: les DD ne > passent-ils pas leur temps � faire qqch que les utilisateurs > ne veulent finalement pas vraiment, et ne serait il pas > mieux pass� � travailler diff�rement (avec les m�mes > ressources... et en changeant les buts). Non, faire comme le veut Georges, c'est peut etre sympa a court terme, mais cela compromet la stabilite de debian a long terme, et cela ne marchera pas de toute facon, le probleme des dependances est bien trop complexe pour que cela puisse marche bien sans un cadre suffisant, et ce que propose Georges n'ammenera qu'un fouilli imonde assez rapidement, et ne sera alors utile pour personne. Moi, en tant que DD, je me refuse a travailler la dessus dans ces conditions. Bien sur, si un cadre satisfaisant etait trouve pour resoudre ce probleme, et qu'un certain nombre de choses bien precise etait necessaire pour que ce projet marche, je le ferrait, mais il faut quelque chose de plus solide qu'un simple "les DD n'ont qu'a travailler dans stable". Amicalement, Sven Luther
