Ici : http://lapwing.org/index.php?option=com_frontpage&Itemid=1
Je cite :
"""
The Lapwing-Linux development cycle is currently as follows;
*
Create a stable aaa_base/ set of packages per every point release
(0.2, 0.3) every 9-12 months,
Pendant combien de temps ?
Then create all the required software above (X.org, GTK2, XFCE
etc) which can be updated/edited/removed as needed, updated continually
over the life of the release,
Et là ils font une release qui pete une machine sur 10 mais trop tard tout
* Bug/security/update fixes as needed,
Et si ca implique de devoir changer un élement de la base ? (type passage de
Ici : http://lapwing.org/index.php?option=com_frontpage&Itemid=1
Je cite :
"""
The Lapwing-Linux development cycle is currently as follows;
*
Create a stable aaa_base/ set of packages per every point release
(0.2, 0.3) every 9-12 months,
Pendant combien de temps ?
Then create all the required software above (X.org, GTK2, XFCE
etc) which can be updated/edited/removed as needed, updated continually
over the life of the release,
Et là ils font une release qui pete une machine sur 10 mais trop tard tout
* Bug/security/update fixes as needed,
Et si ca implique de devoir changer un élement de la base ? (type passage de
Ici : http://lapwing.org/index.php?option=com_frontpage&Itemid=1
Je cite :
"""
The Lapwing-Linux development cycle is currently as follows;
*
Create a stable aaa_base/ set of packages per every point release
(0.2, 0.3) every 9-12 months,
Pendant combien de temps ?
Then create all the required software above (X.org, GTK2, XFCE
etc) which can be updated/edited/removed as needed, updated continually
over the life of the release,
Et là ils font une release qui pete une machine sur 10 mais trop tard tout
* Bug/security/update fixes as needed,
Et si ca implique de devoir changer un élement de la base ? (type passage de
Refaire des packages de base ne se fait pas en 1semaine, et si c'est juste
des petits changements il n'y aurait aucun problème à les intégrer.
Then create all the required software above (X.org, GTK2, XFCE
etc) which can be updated/edited/removed as needed, updated continually
over the life of the release,
Et là ils font une release qui pete une machine sur 10 mais trop tard tout
le monde a déjà fait l'update. (et bon en fait c'est déjà arrivé chez
mandriva parce que justement ils freezaient pas assez avant de faire une
release grand public).
Et sinon euh bon dire que x.org & gtk2 ne font pas partie de la base, je
vois pas ce que contient concretement la base à ce moment là?
Ni même quel interet de considérer le reste (qui se resumerait donc au noyau
+ glibc + boot loader + coreutils ? ) stable, alors que le noyau est une
source d'améliorations fantastiques à chaque release.
* Bug/security/update fixes as needed,
Et si ca implique de devoir changer un élement de la base ? (type passage de
OSS à alsa avec OSS qui n'arriverait pas à gérer les intel8x0)
Refaire des packages de base ne se fait pas en 1semaine, et si c'est juste
des petits changements il n'y aurait aucun problème à les intégrer.
Then create all the required software above (X.org, GTK2, XFCE
etc) which can be updated/edited/removed as needed, updated continually
over the life of the release,
Et là ils font une release qui pete une machine sur 10 mais trop tard tout
le monde a déjà fait l'update. (et bon en fait c'est déjà arrivé chez
mandriva parce que justement ils freezaient pas assez avant de faire une
release grand public).
Et sinon euh bon dire que x.org & gtk2 ne font pas partie de la base, je
vois pas ce que contient concretement la base à ce moment là?
Ni même quel interet de considérer le reste (qui se resumerait donc au noyau
+ glibc + boot loader + coreutils ? ) stable, alors que le noyau est une
source d'améliorations fantastiques à chaque release.
* Bug/security/update fixes as needed,
Et si ca implique de devoir changer un élement de la base ? (type passage de
OSS à alsa avec OSS qui n'arriverait pas à gérer les intel8x0)
Refaire des packages de base ne se fait pas en 1semaine, et si c'est juste
des petits changements il n'y aurait aucun problème à les intégrer.
Then create all the required software above (X.org, GTK2, XFCE
etc) which can be updated/edited/removed as needed, updated continually
over the life of the release,
Et là ils font une release qui pete une machine sur 10 mais trop tard tout
le monde a déjà fait l'update. (et bon en fait c'est déjà arrivé chez
mandriva parce que justement ils freezaient pas assez avant de faire une
release grand public).
Et sinon euh bon dire que x.org & gtk2 ne font pas partie de la base, je
vois pas ce que contient concretement la base à ce moment là?
Ni même quel interet de considérer le reste (qui se resumerait donc au noyau
+ glibc + boot loader + coreutils ? ) stable, alors que le noyau est une
source d'améliorations fantastiques à chaque release.
* Bug/security/update fixes as needed,
Et si ca implique de devoir changer un élement de la base ? (type passage de
OSS à alsa avec OSS qui n'arriverait pas à gérer les intel8x0)
Phh wrote:
Je ne comprends pas ce que tu veux dire.
Bah refaire la base tous les 9 à 12 mois prendra forcement du temps pendant
Et là ils font une release qui pete une machine sur 10 mais trop tard
tout le monde a déjà fait l'update. (et bon en fait c'est déjà arrivé
chez mandriva parce que justement ils freezaient pas assez avant de faire
une release grand public).
Tu parles de la base ou du reste ?
Parce que si c'est de la base, ben ça se passe comme les autres distribs.
Sinon, si tu parles des autres applications, l'intérêt c'est que si ça
casse, seule une application casse (étant donné que tout n'est pas mis à
jour en même temps). Et ça se voit très vite, et en plus les autres
applications restent fonctionnelles.
J'arrive pas à comprendre la relation que tu fais entre «une seule
C'est pour cela que je reste méfiant. En effet, avoir un xorg dans la
base serait un plus (dans l'idéal, il faudrait tout ce qui concerne la
base de l'interface graphique, de l'accès réseau, et du matériel).
Sauf que dans ce cas t'aurais loupé xorg 7.3 (avec entre autre gestion du
Pour les bibliothèques importante comme gtk, je verrais bien un système
de branches (par ex. rester le plus longtemps possible sous la branche
2.10, avant de passer en douceur à gtk 2.12).
C'est assez intéressant comme idée (pas spécialement original j'avoue), mais
Pour le noyau, rien n'empêche de proposer par défaut un noyau stable, et
pour ceux qui ont besoin de nouveaux matos, un iso avec un noyau plus
récent.
Ce n'est pas qu'une question de matos, cf inotify ou fuse en leur temps (bon
En général, les éléments de base interviennent rarement pour les
applications de haut niveau (je veux dire en terme de version).
Mais sinon, il y aura toujours moyen de backporter un bug (c'est ce que
font les autres distribs), donc il n'y a pas trop de soucis de ce côté là.
Et puis, prenons le pire : on ne peut pas mettre à jour l'application X,
parce que la base en est à une version trop vieille. Dans ce cas, on
peut figer cette application en effet. Mais ça se fait au cas par cas,
et c'est déjà mieux que de tout figer comme le font les autres.
"les autres" ne figent en général qu'un mois ou deux (enfin y a différents
Phh wrote:
Je ne comprends pas ce que tu veux dire.
Bah refaire la base tous les 9 à 12 mois prendra forcement du temps pendant
Et là ils font une release qui pete une machine sur 10 mais trop tard
tout le monde a déjà fait l'update. (et bon en fait c'est déjà arrivé
chez mandriva parce que justement ils freezaient pas assez avant de faire
une release grand public).
Tu parles de la base ou du reste ?
Parce que si c'est de la base, ben ça se passe comme les autres distribs.
Sinon, si tu parles des autres applications, l'intérêt c'est que si ça
casse, seule une application casse (étant donné que tout n'est pas mis à
jour en même temps). Et ça se voit très vite, et en plus les autres
applications restent fonctionnelles.
J'arrive pas à comprendre la relation que tu fais entre «une seule
C'est pour cela que je reste méfiant. En effet, avoir un xorg dans la
base serait un plus (dans l'idéal, il faudrait tout ce qui concerne la
base de l'interface graphique, de l'accès réseau, et du matériel).
Sauf que dans ce cas t'aurais loupé xorg 7.3 (avec entre autre gestion du
Pour les bibliothèques importante comme gtk, je verrais bien un système
de branches (par ex. rester le plus longtemps possible sous la branche
2.10, avant de passer en douceur à gtk 2.12).
C'est assez intéressant comme idée (pas spécialement original j'avoue), mais
Pour le noyau, rien n'empêche de proposer par défaut un noyau stable, et
pour ceux qui ont besoin de nouveaux matos, un iso avec un noyau plus
récent.
Ce n'est pas qu'une question de matos, cf inotify ou fuse en leur temps (bon
En général, les éléments de base interviennent rarement pour les
applications de haut niveau (je veux dire en terme de version).
Mais sinon, il y aura toujours moyen de backporter un bug (c'est ce que
font les autres distribs), donc il n'y a pas trop de soucis de ce côté là.
Et puis, prenons le pire : on ne peut pas mettre à jour l'application X,
parce que la base en est à une version trop vieille. Dans ce cas, on
peut figer cette application en effet. Mais ça se fait au cas par cas,
et c'est déjà mieux que de tout figer comme le font les autres.
"les autres" ne figent en général qu'un mois ou deux (enfin y a différents
Phh wrote:
Je ne comprends pas ce que tu veux dire.
Bah refaire la base tous les 9 à 12 mois prendra forcement du temps pendant
Et là ils font une release qui pete une machine sur 10 mais trop tard
tout le monde a déjà fait l'update. (et bon en fait c'est déjà arrivé
chez mandriva parce que justement ils freezaient pas assez avant de faire
une release grand public).
Tu parles de la base ou du reste ?
Parce que si c'est de la base, ben ça se passe comme les autres distribs.
Sinon, si tu parles des autres applications, l'intérêt c'est que si ça
casse, seule une application casse (étant donné que tout n'est pas mis à
jour en même temps). Et ça se voit très vite, et en plus les autres
applications restent fonctionnelles.
J'arrive pas à comprendre la relation que tu fais entre «une seule
C'est pour cela que je reste méfiant. En effet, avoir un xorg dans la
base serait un plus (dans l'idéal, il faudrait tout ce qui concerne la
base de l'interface graphique, de l'accès réseau, et du matériel).
Sauf que dans ce cas t'aurais loupé xorg 7.3 (avec entre autre gestion du
Pour les bibliothèques importante comme gtk, je verrais bien un système
de branches (par ex. rester le plus longtemps possible sous la branche
2.10, avant de passer en douceur à gtk 2.12).
C'est assez intéressant comme idée (pas spécialement original j'avoue), mais
Pour le noyau, rien n'empêche de proposer par défaut un noyau stable, et
pour ceux qui ont besoin de nouveaux matos, un iso avec un noyau plus
récent.
Ce n'est pas qu'une question de matos, cf inotify ou fuse en leur temps (bon
En général, les éléments de base interviennent rarement pour les
applications de haut niveau (je veux dire en terme de version).
Mais sinon, il y aura toujours moyen de backporter un bug (c'est ce que
font les autres distribs), donc il n'y a pas trop de soucis de ce côté là.
Et puis, prenons le pire : on ne peut pas mettre à jour l'application X,
parce que la base en est à une version trop vieille. Dans ce cas, on
peut figer cette application en effet. Mais ça se fait au cas par cas,
et c'est déjà mieux que de tout figer comme le font les autres.
"les autres" ne figent en général qu'un mois ou deux (enfin y a différents
Sauf que dans ce cas t'aurais loupé xorg 7.3 (avec entre autre gestion du
hotplug un peu partout), sauf si t'avais refais ta base au début de xorg
7.3, mais dans ce cas ca n'aurait pas forcement était stable, donc faudrait
une base qui se mette à jour en fonction de xorg, mais aussi du noyau, bah
en fait faudrait une base stable dynamique. Oops
Sauf que dans ce cas t'aurais loupé xorg 7.3 (avec entre autre gestion du
hotplug un peu partout), sauf si t'avais refais ta base au début de xorg
7.3, mais dans ce cas ca n'aurait pas forcement était stable, donc faudrait
une base qui se mette à jour en fonction de xorg, mais aussi du noyau, bah
en fait faudrait une base stable dynamique. Oops
Sauf que dans ce cas t'aurais loupé xorg 7.3 (avec entre autre gestion du
hotplug un peu partout), sauf si t'avais refais ta base au début de xorg
7.3, mais dans ce cas ca n'aurait pas forcement était stable, donc faudrait
une base qui se mette à jour en fonction de xorg, mais aussi du noyau, bah
en fait faudrait une base stable dynamique. Oops