[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))



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).

- 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
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.

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. 

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)?

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?

> 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.

> 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).

/Y - poseur de questions.
 
-- 
Marbles should be kept together.



Reply to: