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

Re: Cahier de doléances pour Debian



Le 24.01.02, Raphael Hertzog a tapoté :

| Bonjour,

	Salut.


| j'envisage de me présenter aux élections Debian qui approchent.

	Excellente idée !


| Donc, je me permets de lancer cette enfilade "cahier de doléances"
| pour recevoir vos idées/requêtes/problèmes.

	Très bonne idée aussi.


| Je vous demande de rester relativement concret, ce n'est pas la
| peine de me dire "on veut des release stable plus souvent", ca tout le
| monde le sait et tout le monde le veut. Par contre si vous avez
| des idées sur comment y parvenir, alors oui n'hésitez pas. Ce qui
| m'intéresse aussi c'est tout ce que vous pouvez avoir à dire/suggérer autour
| de l'image de Debian, de la communication de Debian, de son organisation
| interne, de sa manière d'être en contact avec ses utilisateurs, de la
| manière de collaborer avec les développeurs, etc.

	Après plusieurs années d'utilisation de cette distro
	exceptionnelle ainsi que d'autres (Slack principalement) mais
	aussi d'autres OS (BSD, Solaris...) j'ai pris quelques habitudes
	basée sur une longue réflexion et de grandes discussions que ce
	soit sur cette ml ou sur les newsgroups.

	À l'heure actuelle, une grande partie des installations de Linux
	et de la Debian en particulier se font sur des machines en
	environnement réseau. Les améliorations que je propose permettent
	non seulement de simplifier l'installation en réseau (eg : un
	serveur d'applis et des clients) ainsi que de facilité la mise à
	jour plus rapide des paquetages.

	Cette modification a déjà été évoquée : il s'agit de découper
	l'ensemble des paquetages en 2 parties. D'une part les paquetages
	concernant la base du système (en fait surtout faisant la base
	d'un système unix minimal mais néanmoins fonctionnel). Et d'autre
	part tous les autres paquetages.

	Ce qui fait la spécificité de ce système est que les releases de
	la base de l'OS sont plus facile et rapides. De plus, si l'on
	joint à cela le fait d'avoir des paquets non-de-base (extra)
	compilés pour la dernière version de base, la mise à jour est
	grandement facilitée : en effet, il n'est plus nécessaire d'avoir
	des paquets unstable mais uniquement stable/testing, ces derniers
	n'étant disponible que pour tester les nouvelles fonctionnalités
	du logiciel incriminé. De plus, l'indépendance nécessaire par
	rapport à la base (dans le sens des mises-à-jour) et la limitation
	des dépendances envers les autres paquets est indispensable.

	Enfin, ce découpage base/extra associé à des paquets relocatable
	(fr ?) (je sais on en a déjà beaucoup parlé) pour les paquets
	extra, permettrait, si l'on spécifie un préfix particulier pour
	tous ces paquets, de les installer/upgrader facilement dans un
	environnement réseau. Il ne nécessiterait plus que l'installation
	de la base sur toutes les machines, des paquets choisis sur le
	serveur de fichiers épicétou !

	L'avantage est que ce serait aussi valable pour une station seule.

	Bien sûr une bonne ergonomie est indispensable (ergonomie ne veut
	pas forcément dire fenêtres/graphique, hein :) : une présentation
	claire des étapes (tenant dans un écran de 24 lignes) passées et
	futures (mieux que ce qui est actuellement fait) serait un plus
	indéniable.


Thomas -- grain de sel
-- 
BOFH excuse #190:
Proprietary Information.







Reply to: