Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
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
Reply to: