Le Sat, 09 Mar 2013 15:03:15 +0100
maderios a écrit:Le problème des paquets obsolètes se résoud en mélangant sid et testing.
Même pas vu que plus rien ne rentre dans sid. Pour rester sur libreoffice, sid
en est toujours à la 3.5.4.
Si on veut être à jour il faut s'aventurer dans experimental mais là ça
devient vite scabreux.
Gaëtan
Le Sat, 09 Mar 2013 15:03:15 +0100
maderios <maderios@gmail.com> a écrit:
Le problème des paquets obsolètes se résoud en mélangant sid et testing.
Même pas vu que plus rien ne rentre dans sid. Pour rester sur libreoffice, sid
en est toujours à la 3.5.4.
Si on veut être à jour il faut s'aventurer dans experimental mais là ça
devient vite scabreux.
Gaëtan
Le Sat, 09 Mar 2013 15:03:15 +0100
maderios a écrit:Le problème des paquets obsolètes se résoud en mélangant sid et testing.
Même pas vu que plus rien ne rentre dans sid. Pour rester sur libreoffice, sid
en est toujours à la 3.5.4.
Si on veut être à jour il faut s'aventurer dans experimental mais là ça
devient vite scabreux.
Gaëtan
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
Ma question est précisement serait-il à votre avis intéres sant de découper la distribution
en plusieurs projets (core, server, desktop...) qui pourrait avoir des cy cle de vie
différents ? ou bien de limiter l'évolution de la stable en ren trant 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 assoupl ir pour les environements
graphiques)...
Ma question est précisement serait-il à votre avis intéres sant de découper la distribution
en plusieurs projets (core, server, desktop...) qui pourrait avoir des cy cle de vie
différents ? ou bien de limiter l'évolution de la stable en ren trant 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 assoupl ir pour les environements
graphiques)...
Ma question est précisement serait-il à votre avis intéres sant de découper la distribution
en plusieurs projets (core, server, desktop...) qui pourrait avoir des cy cle de vie
différents ? ou bien de limiter l'évolution de la stable en ren trant 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 assoupl ir pour les environements
graphiques)...
Il est certain qu'avec lâessor de plus en plus important des logi ciels
libres et de l'usage de linux en desktop, qu'il va devenir difficile de
maintenir une distribution comme Debian tout en y ajoutant de plus en
plus de paquets.
Il est certain qu'avec lâessor de plus en plus important des logi ciels
libres et de l'usage de linux en desktop, qu'il va devenir difficile de
maintenir une distribution comme Debian tout en y ajoutant de plus en
plus de paquets.
Il est certain qu'avec lâessor de plus en plus important des logi ciels
libres et de l'usage de linux en desktop, qu'il va devenir difficile de
maintenir une distribution comme Debian tout en y ajoutant de plus en
plus de paquets.
Bonjour à tous les utilisateurs et développeurs de Debian :
Dans son message du 09/03/13 à 11:23, Mourad a écrit :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)...
Hum, si j'ai choisi Debian (et sa version stable c'est-à-dire "Squeeze") pour mon ordinateur fixe, même dans le cadre de l'utilisation bureautique (entre autres...), ce n'est pas par hasard ! Par conséquent, je suis plutôt pour le maintien (de manière aussi rigoureuse que possible) de la règle qui veut qu'une nouvelle stable ne sera délivrée une fois qu'elle sera bien testée, "debuggée" et sécurisée (voir http://www.debian.org/doc/manuals/debian-faq/ch-ftparchives.fr.html#s-frozen ) dans son intégralité et pas seulement les paquets pour les serveurs. :-|
Bonjour à tous les utilisateurs et développeurs de Debian :
Dans son message du 09/03/13 à 11:23, Mourad a écrit :
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)...
Hum, si j'ai choisi Debian (et sa version stable c'est-à-dire "Squeeze") pour mon ordinateur fixe, même dans le cadre de l'utilisation bureautique (entre autres...), ce n'est pas par hasard ! Par conséquent, je suis plutôt pour le maintien (de manière aussi rigoureuse que possible) de la règle qui veut qu'une nouvelle stable ne sera délivrée une fois qu'elle sera bien testée, "debuggée" et sécurisée (voir http://www.debian.org/doc/manuals/debian-faq/ch-ftparchives.fr.html#s-frozen ) dans son intégralité et pas seulement les paquets pour les serveurs. :-|
Bonjour à tous les utilisateurs et développeurs de Debian :
Dans son message du 09/03/13 à 11:23, Mourad a écrit :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)...
Hum, si j'ai choisi Debian (et sa version stable c'est-à-dire "Squeeze") pour mon ordinateur fixe, même dans le cadre de l'utilisation bureautique (entre autres...), ce n'est pas par hasard ! Par conséquent, je suis plutôt pour le maintien (de manière aussi rigoureuse que possible) de la règle qui veut qu'une nouvelle stable ne sera délivrée une fois qu'elle sera bien testée, "debuggée" et sécurisée (voir http://www.debian.org/doc/manuals/debian-faq/ch-ftparchives.fr.html#s-frozen ) dans son intégralité et pas seulement les paquets pour les serveurs. :-|
[â¦]
Salut
[â¦]
- dimension souvent ignorée: on peut facilement attendre 2
ans quand l'on est âgé de 25 ou 30 ans. A 60 ans, on tique
fortement. Et à 80 ans, cela n'a certainement plus de
sens......
[â¦]
Salut
[â¦]
- dimension souvent ignorée: on peut facilement attendre 2
ans quand l'on est âgé de 25 ou 30 ans. A 60 ans, on tique
fortement. Et à 80 ans, cela n'a certainement plus de
sens......
[â¦]
Salut
[â¦]
- dimension souvent ignorée: on peut facilement attendre 2
ans quand l'on est âgé de 25 ou 30 ans. A 60 ans, on tique
fortement. Et à 80 ans, cela n'a certainement plus de
sens......
Le dimanche 10 mars 2013 à 10:47:36, maderios a écrit :[…]
Salut
’lut,[…]
- dimension souvent ignorée: on peut facilement attendre 2
ans quand l'on est âgé de 25 ou 30 ans. A 60 ans, on tique
fortement. Et à 80 ans, cela n'a certainement plus de
sens......
Et moi qui pensait que l’impatience était l’apanage de la
jeunesse… ou est-ce que c’était la patience qui était censée
venir avec l’âge… ’fin bref le contraire quoi…
Le dimanche 10 mars 2013 à 10:47:36, maderios a écrit :
[…]
Salut
’lut,
[…]
- dimension souvent ignorée: on peut facilement attendre 2
ans quand l'on est âgé de 25 ou 30 ans. A 60 ans, on tique
fortement. Et à 80 ans, cela n'a certainement plus de
sens......
Et moi qui pensait que l’impatience était l’apanage de la
jeunesse… ou est-ce que c’était la patience qui était censée
venir avec l’âge… ’fin bref le contraire quoi…
Le dimanche 10 mars 2013 à 10:47:36, maderios a écrit :[…]
Salut
’lut,[…]
- dimension souvent ignorée: on peut facilement attendre 2
ans quand l'on est âgé de 25 ou 30 ans. A 60 ans, on tique
fortement. Et à 80 ans, cela n'a certainement plus de
sens......
Et moi qui pensait que l’impatience était l’apanage de la
jeunesse… ou est-ce que c’était la patience qui était censée
venir avec l’âge… ’fin bref le contraire quoi…
Bonjour
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 plus 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
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 plus 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
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 plus 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.
Hum, si j'ai choisi Debian (et sa version stable c'est-à-dire "Squeeze") pour mon ordinateur fixe, même dans le cadre de l'utilisation bureautique (entre autres...), ce n'est pas par hasard ! Par conséquent, je suis plutôt pour le maintien (de manière aussi rigoureuse que possible) de la règle qui veut qu'une nouvelle stable ne sera délivrée une fois qu'elle sera bien testée, "debuggée" et sécurisée (voir http://www.debian.org/doc/manuals/debian-faq/ch-ftparchives.fr.html#s-frozen ) dans son intégralité et pas seulement les paquets pour les serveurs. :-|
Hum, si j'ai choisi Debian (et sa version stable c'est-à-dire "Squeeze") pour mon ordinateur fixe, même dans le cadre de l'utilisation bureautique (entre autres...), ce n'est pas par hasard ! Par conséquent, je suis plutôt pour le maintien (de manière aussi rigoureuse que possible) de la règle qui veut qu'une nouvelle stable ne sera délivrée une fois qu'elle sera bien testée, "debuggée" et sécurisée (voir http://www.debian.org/doc/manuals/debian-faq/ch-ftparchives.fr.html#s-frozen ) dans son intégralité et pas seulement les paquets pour les serveurs. :-|
Hum, si j'ai choisi Debian (et sa version stable c'est-à-dire "Squeeze") pour mon ordinateur fixe, même dans le cadre de l'utilisation bureautique (entre autres...), ce n'est pas par hasard ! Par conséquent, je suis plutôt pour le maintien (de manière aussi rigoureuse que possible) de la règle qui veut qu'une nouvelle stable ne sera délivrée une fois qu'elle sera bien testée, "debuggée" et sécurisée (voir http://www.debian.org/doc/manuals/debian-faq/ch-ftparchives.fr.html#s-frozen ) dans son intégralité et pas seulement les paquets pour les serveurs. :-|
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 de s versions
plus performantes.
- quant certains bugs ne sont pas corrigés alors qu'ils le sont dans les
dernières versions des logiciels.
- dimension souvent ignorée: on peut facilement attendre 2 ans quand
l'on est âgé de 25 ou 30 ans. A 60 ans, on tique fortement. Et à 80
ans, cela n'a certainement plus de sens......
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 de s versions
plus performantes.
- quant certains bugs ne sont pas corrigés alors qu'ils le sont dans les
dernières versions des logiciels.
- dimension souvent ignorée: on peut facilement attendre 2 ans quand
l'on est âgé de 25 ou 30 ans. A 60 ans, on tique fortement. Et à 80
ans, cela n'a certainement plus de sens......
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 de s versions
plus performantes.
- quant certains bugs ne sont pas corrigés alors qu'ils le sont dans les
dernières versions des logiciels.
- dimension souvent ignorée: on peut facilement attendre 2 ans quand
l'on est âgé de 25 ou 30 ans. A 60 ans, on tique fortement. Et à 80
ans, cela n'a certainement plus de sens......
