Patience dans certains contextes, certes.... Par contre, quand l'on ne
croit ni à l'immortalité ni au père noël, les debian stables, avec
"l'âge", on s'en tape de plus en plus.... Je dirais même que pl us on
vieillit, plus on aime jouer avec l'incertitude. Oui, cela paraît
contradictoire mais c'est une méthode pour garder la forme. Certains
font des sudoku, d'autres bidouillent leur système.
Patience dans certains contextes, certes.... Par contre, quand l'on ne
croit ni à l'immortalité ni au père noël, les debian stables, avec
"l'âge", on s'en tape de plus en plus.... Je dirais même que pl us on
vieillit, plus on aime jouer avec l'incertitude. Oui, cela paraît
contradictoire mais c'est une méthode pour garder la forme. Certains
font des sudoku, d'autres bidouillent leur système.
Patience dans certains contextes, certes.... Par contre, quand l'on ne
croit ni à l'immortalité ni au père noël, les debian stables, avec
"l'âge", on s'en tape de plus en plus.... Je dirais même que pl us on
vieillit, plus on aime jouer avec l'incertitude. Oui, cela paraît
contradictoire mais c'est une méthode pour garder la forme. Certains
font des sudoku, d'autres bidouillent leur système.
Bonjour à tous les utilisateurs et développeurs de Debian :
Dans son message du 10/03/13 à 10:47, Maderios a écrit :La stable qui stagne pendant 2 ans pose des problèmes.
Exemples vécus (liste non exhaustive)
- quand elle ne suit pas l'évolution du matériel
- quand certains paquets sont complètement dépassés par des versions
plus performantes.
A mon avis, c'est, avant tout, un choix entre les versions "stable", "testing", "unstable" voire "experimental" pour les plus aventureux (euh très peu pour moi :-( ou alors, peut-être un jour, dans le cadre d'un machine virtuelle avec VirtualBox).
Comme cela est expliqué dans la FAQ Debian GNU/Linux (voir la page http://www.debian.org/doc/manuals/debian-faq/ch-choosing.fr.html#s3.1 ), concernant les "qualités" et les "défauts" de chaque version, on pourrait schématiser de la façon suivante (du moins c'est ainsi que je comprends) :
Stable >> Testing >> Unstable >> Experimental
Plus sûre >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moins sûre
Moins déboguée >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Plus déboguée
Plus ancienne >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Plus récente (a)
Moins compatible >>>>>>>>>>>>>>>>>>>>>>>>> Plus compatible (b)
Et on pourrait énumérer éventuellement d'autres qualités ou défauts. ;-)
(a) Je parle des logiciels que peut proposer une telle version.
(b) Ici, il s'agit des composants internes (processeur, mémoire de masse, carte graphique,...) ou des périphériques externes (écran, imprimante, scanner,...) pris en charge par une telle version (de façon plus ou moins... optimisée mais cela est un autre débat).
A partir de là, chacun fera son choix en fonction de ses besoins et des ses souhaits et, surtout, en connaissance de cause.
Pour le reste et pour en revenir au débat initial, je continue à penser tout à fait pertinent le choix de Debian qui consiste (en gros) :
- (1) à gérer les 4 (ou même 5 si on ajoute "oldstable") versions de manière différenciée en fonction de leurs objectifs,
- (2) à décider si un paquet (selon sa propre version) peut entrer dans une version (autre que Stable) en fonction de la conformité de ses exigences que notre distribution préférée (dont certains jugeront un rien perfectionniste) s'est elle-même fixée et
- (3) à juger si Testing (et, avec elle, les milliers de paquets ce qui démontre, entre autres, toute la difficulté de la tâche) peut devenir, à un moment donné, la nouvelle Stable si elle remplit les critères de qualités qui convient à cette version... quitte à attendre plus de 6 mois (ou même plus de 2 ans ;-) ).- quant certains bugs ne sont pas corrigés alors qu'ils le sont dans les
dernières versions des logiciels.
Euh, je ne sais pas trop de quels bugs tu veux parler (même si je ne conteste pas leur existence vu que j'intègre les mises à jour de sécurité pour ma Stable tous les lundis matin quand il y en a) mais, là encore, les bugs contenus dans Experimental, Unstable ou Testing (du moins avant sa période de gel et encore c'est à vérifier) sont, probablement, plus nombreux et moins anodins que ceux de Stable. :-|
Bonjour à tous les utilisateurs et développeurs de Debian :
Dans son message du 10/03/13 à 10:47, Maderios a écrit :
La stable qui stagne pendant 2 ans pose des problèmes.
Exemples vécus (liste non exhaustive)
- quand elle ne suit pas l'évolution du matériel
- quand certains paquets sont complètement dépassés par des versions
plus performantes.
A mon avis, c'est, avant tout, un choix entre les versions "stable", "testing", "unstable" voire "experimental" pour les plus aventureux (euh très peu pour moi :-( ou alors, peut-être un jour, dans le cadre d'un machine virtuelle avec VirtualBox).
Comme cela est expliqué dans la FAQ Debian GNU/Linux (voir la page http://www.debian.org/doc/manuals/debian-faq/ch-choosing.fr.html#s3.1 ), concernant les "qualités" et les "défauts" de chaque version, on pourrait schématiser de la façon suivante (du moins c'est ainsi que je comprends) :
Stable >> Testing >> Unstable >> Experimental
Plus sûre >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moins sûre
Moins déboguée >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Plus déboguée
Plus ancienne >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Plus récente (a)
Moins compatible >>>>>>>>>>>>>>>>>>>>>>>>> Plus compatible (b)
Et on pourrait énumérer éventuellement d'autres qualités ou défauts. ;-)
(a) Je parle des logiciels que peut proposer une telle version.
(b) Ici, il s'agit des composants internes (processeur, mémoire de masse, carte graphique,...) ou des périphériques externes (écran, imprimante, scanner,...) pris en charge par une telle version (de façon plus ou moins... optimisée mais cela est un autre débat).
A partir de là, chacun fera son choix en fonction de ses besoins et des ses souhaits et, surtout, en connaissance de cause.
Pour le reste et pour en revenir au débat initial, je continue à penser tout à fait pertinent le choix de Debian qui consiste (en gros) :
- (1) à gérer les 4 (ou même 5 si on ajoute "oldstable") versions de manière différenciée en fonction de leurs objectifs,
- (2) à décider si un paquet (selon sa propre version) peut entrer dans une version (autre que Stable) en fonction de la conformité de ses exigences que notre distribution préférée (dont certains jugeront un rien perfectionniste) s'est elle-même fixée et
- (3) à juger si Testing (et, avec elle, les milliers de paquets ce qui démontre, entre autres, toute la difficulté de la tâche) peut devenir, à un moment donné, la nouvelle Stable si elle remplit les critères de qualités qui convient à cette version... quitte à attendre plus de 6 mois (ou même plus de 2 ans ;-) ).
- quant certains bugs ne sont pas corrigés alors qu'ils le sont dans les
dernières versions des logiciels.
Euh, je ne sais pas trop de quels bugs tu veux parler (même si je ne conteste pas leur existence vu que j'intègre les mises à jour de sécurité pour ma Stable tous les lundis matin quand il y en a) mais, là encore, les bugs contenus dans Experimental, Unstable ou Testing (du moins avant sa période de gel et encore c'est à vérifier) sont, probablement, plus nombreux et moins anodins que ceux de Stable. :-|
Bonjour à tous les utilisateurs et développeurs de Debian :
Dans son message du 10/03/13 à 10:47, Maderios a écrit :La stable qui stagne pendant 2 ans pose des problèmes.
Exemples vécus (liste non exhaustive)
- quand elle ne suit pas l'évolution du matériel
- quand certains paquets sont complètement dépassés par des versions
plus performantes.
A mon avis, c'est, avant tout, un choix entre les versions "stable", "testing", "unstable" voire "experimental" pour les plus aventureux (euh très peu pour moi :-( ou alors, peut-être un jour, dans le cadre d'un machine virtuelle avec VirtualBox).
Comme cela est expliqué dans la FAQ Debian GNU/Linux (voir la page http://www.debian.org/doc/manuals/debian-faq/ch-choosing.fr.html#s3.1 ), concernant les "qualités" et les "défauts" de chaque version, on pourrait schématiser de la façon suivante (du moins c'est ainsi que je comprends) :
Stable >> Testing >> Unstable >> Experimental
Plus sûre >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moins sûre
Moins déboguée >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Plus déboguée
Plus ancienne >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Plus récente (a)
Moins compatible >>>>>>>>>>>>>>>>>>>>>>>>> Plus compatible (b)
Et on pourrait énumérer éventuellement d'autres qualités ou défauts. ;-)
(a) Je parle des logiciels que peut proposer une telle version.
(b) Ici, il s'agit des composants internes (processeur, mémoire de masse, carte graphique,...) ou des périphériques externes (écran, imprimante, scanner,...) pris en charge par une telle version (de façon plus ou moins... optimisée mais cela est un autre débat).
A partir de là, chacun fera son choix en fonction de ses besoins et des ses souhaits et, surtout, en connaissance de cause.
Pour le reste et pour en revenir au débat initial, je continue à penser tout à fait pertinent le choix de Debian qui consiste (en gros) :
- (1) à gérer les 4 (ou même 5 si on ajoute "oldstable") versions de manière différenciée en fonction de leurs objectifs,
- (2) à décider si un paquet (selon sa propre version) peut entrer dans une version (autre que Stable) en fonction de la conformité de ses exigences que notre distribution préférée (dont certains jugeront un rien perfectionniste) s'est elle-même fixée et
- (3) à juger si Testing (et, avec elle, les milliers de paquets ce qui démontre, entre autres, toute la difficulté de la tâche) peut devenir, à un moment donné, la nouvelle Stable si elle remplit les critères de qualités qui convient à cette version... quitte à attendre plus de 6 mois (ou même plus de 2 ans ;-) ).- quant certains bugs ne sont pas corrigés alors qu'ils le sont dans les
dernières versions des logiciels.
Euh, je ne sais pas trop de quels bugs tu veux parler (même si je ne conteste pas leur existence vu que j'intègre les mises à jour de sécurité pour ma Stable tous les lundis matin quand il y en a) mais, là encore, les bugs contenus dans Experimental, Unstable ou Testing (du moins avant sa période de gel et encore c'est à vérifier) sont, probablement, plus nombreux et moins anodins que ceux de Stable. :-|
Je préfère une debian sectionnée et c'est ce que j'essaie d'appliquer
depuis longtemps.
- une base fiable au maximum pour le kernel, le réseau, tout ce qui
concerne la stabilité du système lui-même, l'affichage
- des appli plus avancées, si nécessaire venant de sid ou compi lées
depuis les sources, appli ne mettant pas en cause la sécurité o u la
stabilité
Je préfère une debian sectionnée et c'est ce que j'essaie d'appliquer
depuis longtemps.
- une base fiable au maximum pour le kernel, le réseau, tout ce qui
concerne la stabilité du système lui-même, l'affichage
- des appli plus avancées, si nécessaire venant de sid ou compi lées
depuis les sources, appli ne mettant pas en cause la sécurité o u la
stabilité
Je préfère une debian sectionnée et c'est ce que j'essaie d'appliquer
depuis longtemps.
- une base fiable au maximum pour le kernel, le réseau, tout ce qui
concerne la stabilité du système lui-même, l'affichage
- des appli plus avancées, si nécessaire venant de sid ou compi lées
depuis les sources, appli ne mettant pas en cause la sécurité o u la
stabilité
Bonjour,
Ma question est précisement serait-il à votre avis inté ressant de découper
la distribution en plusieurs projets (core, server, desktop...) qui
pourrait avoir des cycle de vie différents ? ou bien de limiter
l'évolution de la stable en rentrant en freezing tous les 6 mois / 1 an
après la release?
Je pense que cela aurait un impact positif sur les temps de release ( par
exemple conserver les mêmes règles pour core et server (0 b ugs RC) et les
assouplir pour les environements graphiques)...
Bonjour,
Ma question est précisement serait-il à votre avis inté ressant de découper
la distribution en plusieurs projets (core, server, desktop...) qui
pourrait avoir des cycle de vie différents ? ou bien de limiter
l'évolution de la stable en rentrant en freezing tous les 6 mois / 1 an
après la release?
Je pense que cela aurait un impact positif sur les temps de release ( par
exemple conserver les mêmes règles pour core et server (0 b ugs RC) et les
assouplir pour les environements graphiques)...
Bonjour,
Ma question est précisement serait-il à votre avis inté ressant de découper
la distribution en plusieurs projets (core, server, desktop...) qui
pourrait avoir des cycle de vie différents ? ou bien de limiter
l'évolution de la stable en rentrant en freezing tous les 6 mois / 1 an
après la release?
Je pense que cela aurait un impact positif sur les temps de release ( par
exemple conserver les mêmes règles pour core et server (0 b ugs RC) et les
assouplir pour les environements graphiques)...
à mon avis c'est prendre le problème à l'envers : si à §a traine, c'est que
certaines équipes de packageurs ne fournissent pas pour corriger tou s les
bugs⦠Découper Debian ne changera strictement rien à ce problème, s'il n'y a
pas plus de monde pour maintenir les paquets.
Je ne suis pas sûr que créer une Debian à deux vitesses so ient bénéfiques⦠Ã
mon avis la bonne solution serait d'avoir des équipes de mainteneurs plus
étoffées⦠Reste à voir comment convaincre les gens de donner du temps pour
leur distribution favoriteâ¦
à mon avis c'est prendre le problème à l'envers : si à §a traine, c'est que
certaines équipes de packageurs ne fournissent pas pour corriger tou s les
bugs⦠Découper Debian ne changera strictement rien à ce problème, s'il n'y a
pas plus de monde pour maintenir les paquets.
Je ne suis pas sûr que créer une Debian à deux vitesses so ient bénéfiques⦠Ã
mon avis la bonne solution serait d'avoir des équipes de mainteneurs plus
étoffées⦠Reste à voir comment convaincre les gens de donner du temps pour
leur distribution favoriteâ¦
à mon avis c'est prendre le problème à l'envers : si à §a traine, c'est que
certaines équipes de packageurs ne fournissent pas pour corriger tou s les
bugs⦠Découper Debian ne changera strictement rien à ce problème, s'il n'y a
pas plus de monde pour maintenir les paquets.
Je ne suis pas sûr que créer une Debian à deux vitesses so ient bénéfiques⦠Ã
mon avis la bonne solution serait d'avoir des équipes de mainteneurs plus
étoffées⦠Reste à voir comment convaincre les gens de donner du temps pour
leur distribution favoriteâ¦
Je ne suis pas sûr que créer une Debian à deux vitesses soient bénéfiques… À
>mon avis la bonne solution serait d'avoir des équipes de mainteneurs plus
>étoffées… Reste à voir comment convaincre les gens de donner du temps pour
>leur distribution favorite…
De toute façon, avec Ubuntu (qui se base sur Unstable), la "Debian à deux vitesses" existe déjà d'une certaine façon... Et, sans être extravaguant, on peut même parler de Debian à trois vitesses avec l'apparition de Linux Mint (dont sa version LMDE dérive de Testing).
Je ne suis pas sûr que créer une Debian à deux vitesses soient bénéfiques… À
>mon avis la bonne solution serait d'avoir des équipes de mainteneurs plus
>étoffées… Reste à voir comment convaincre les gens de donner du temps pour
>leur distribution favorite…
De toute façon, avec Ubuntu (qui se base sur Unstable), la "Debian à deux vitesses" existe déjà d'une certaine façon... Et, sans être extravaguant, on peut même parler de Debian à trois vitesses avec l'apparition de Linux Mint (dont sa version LMDE dérive de Testing).
Je ne suis pas sûr que créer une Debian à deux vitesses soient bénéfiques… À
>mon avis la bonne solution serait d'avoir des équipes de mainteneurs plus
>étoffées… Reste à voir comment convaincre les gens de donner du temps pour
>leur distribution favorite…
De toute façon, avec Ubuntu (qui se base sur Unstable), la "Debian à deux vitesses" existe déjà d'une certaine façon... Et, sans être extravaguant, on peut même parler de Debian à trois vitesses avec l'apparition de Linux Mint (dont sa version LMDE dérive de Testing).
En même temps, la deuxième vitesse de debian , ne se porte pas si mal
que cela, en particulier sur le poste de travail ...
(pour l'utiliser depuis la 8.04 jusqu'à la 10.04, après, c'est devenu un
peu n'importe quoi ...).
Les puristes la détestent assez vite, en même temps, j'ai de la
Slackware sur mes serveurs perso, mais si on veut faire dans l'efficace
pour le poste de travail , Ubuntu ca se pose la. (comment ca
contradictoire ? ;) ).
En même temps, la deuxième vitesse de debian , ne se porte pas si mal
que cela, en particulier sur le poste de travail ...
(pour l'utiliser depuis la 8.04 jusqu'à la 10.04, après, c'est devenu un
peu n'importe quoi ...).
Les puristes la détestent assez vite, en même temps, j'ai de la
Slackware sur mes serveurs perso, mais si on veut faire dans l'efficace
pour le poste de travail , Ubuntu ca se pose la. (comment ca
contradictoire ? ;) ).
En même temps, la deuxième vitesse de debian , ne se porte pas si mal
que cela, en particulier sur le poste de travail ...
(pour l'utiliser depuis la 8.04 jusqu'à la 10.04, après, c'est devenu un
peu n'importe quoi ...).
Les puristes la détestent assez vite, en même temps, j'ai de la
Slackware sur mes serveurs perso, mais si on veut faire dans l'efficace
pour le poste de travail , Ubuntu ca se pose la. (comment ca
contradictoire ? ;) ).
Bonjour,
C'est une question qui me taraude depuis quelques temps déjà...
Ne serions-nous pas arrivé à la limite du process de livraison des version stable de
Debian ?
Nous allons entamer le 10éme mois de freezing et il reste encore + de 150 bugs Release
Critical...
Au rythme actuel de résolution (1.1 bugs par jour), la debian Stable sera livrée dans +
de 6 mois !
Ma question est précisement serait-il à votre avis intéressant de découper la
distribution en plusieurs projets (core, server, desktop...) qui pourrait avoir des
cycle de vie différents ? ou bien de limiter l'évolution de la stable en rentrant en
freezing tous les 6 mois / 1 an après la release?
Je pense que cela aurait un impact positif sur les temps de release (par exemple
conserver les mêmes règles pour core et server (0 bugs RC) et les assouplir pour les
environements graphiques)...
Qu'en pensez-vous ?
++
Mourad
Bonjour,
C'est une question qui me taraude depuis quelques temps déjà...
Ne serions-nous pas arrivé à la limite du process de livraison des version stable de
Debian ?
Nous allons entamer le 10éme mois de freezing et il reste encore + de 150 bugs Release
Critical...
Au rythme actuel de résolution (1.1 bugs par jour), la debian Stable sera livrée dans +
de 6 mois !
Ma question est précisement serait-il à votre avis intéressant de découper la
distribution en plusieurs projets (core, server, desktop...) qui pourrait avoir des
cycle de vie différents ? ou bien de limiter l'évolution de la stable en rentrant en
freezing tous les 6 mois / 1 an après la release?
Je pense que cela aurait un impact positif sur les temps de release (par exemple
conserver les mêmes règles pour core et server (0 bugs RC) et les assouplir pour les
environements graphiques)...
Qu'en pensez-vous ?
++
Mourad
Bonjour,
C'est une question qui me taraude depuis quelques temps déjà...
Ne serions-nous pas arrivé à la limite du process de livraison des version stable de
Debian ?
Nous allons entamer le 10éme mois de freezing et il reste encore + de 150 bugs Release
Critical...
Au rythme actuel de résolution (1.1 bugs par jour), la debian Stable sera livrée dans +
de 6 mois !
Ma question est précisement serait-il à votre avis intéressant de découper la
distribution en plusieurs projets (core, server, desktop...) qui pourrait avoir des
cycle de vie différents ? ou bien de limiter l'évolution de la stable en rentrant en
freezing tous les 6 mois / 1 an après la release?
Je pense que cela aurait un impact positif sur les temps de release (par exemple
conserver les mêmes règles pour core et server (0 bugs RC) et les assouplir pour les
environements graphiques)...
Qu'en pensez-vous ?
++
Mourad
On Sun, 17 Mar 2013 11:32:18 +0100
Mourad Jaber wrote:
IMHO ce que tu proposes nécessiterait au bas mot de tripler
les équipes Debian (avec des gens compétents), ce qui parait
peu évident à réaliser.
Comme dans bien des cas, Debian représente un compromis,
et comme le mieux est bien souvent l'ennemi du bien…
On Sun, 17 Mar 2013 11:32:18 +0100
Mourad Jaber <ml@nativobject.net> wrote:
IMHO ce que tu proposes nécessiterait au bas mot de tripler
les équipes Debian (avec des gens compétents), ce qui parait
peu évident à réaliser.
Comme dans bien des cas, Debian représente un compromis,
et comme le mieux est bien souvent l'ennemi du bien…
On Sun, 17 Mar 2013 11:32:18 +0100
Mourad Jaber wrote:
IMHO ce que tu proposes nécessiterait au bas mot de tripler
les équipes Debian (avec des gens compétents), ce qui parait
peu évident à réaliser.
Comme dans bien des cas, Debian représente un compromis,
et comme le mieux est bien souvent l'ennemi du bien…