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,
*
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,
*
Bug/security/update fixes as needed,
This is a fairly new method of working, using a stable base and working
off it, as outlined here:
http://modeemi.fi/~tuomov/b/archives/2007/03/03/T19_15_26/
"""
Vous avez bien lu, il y a le lien vers mon lien préféré ^________^
Il faut que je l'étudie encore, que je l'installe, et on verra !
(le développement de Gniarf Linux continue, au cas où).
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 ?
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)
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 ?
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)
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 ?
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)
ciol
Phh wrote:
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.
Je ne comprends pas ce que tu veux dire.
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).
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.
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.
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). 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). 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.
* 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)
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.
Phh wrote:
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.
Je ne comprends pas ce que tu veux dire.
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).
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.
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.
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).
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).
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.
* 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)
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.
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.
Je ne comprends pas ce que tu veux dire.
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).
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.
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.
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). 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). 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.
* 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)
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.
Phh
ciol wrote:
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
lequel il est assez difficile d'évoluer sur le reste (ce que fait la plupart des distributions en ce qui concerne gcc 4* en fait)
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
application casse» et «tout n'est pas mis à jour en même temps». Si disons k3b casse (exemple totalement pris au pif), si les mises à jours sont d'un coup ou progressivement, en quoi rythmbox (toujours completement au pif) pourrait être touché d'une quelconque maniere (en supposant avoir
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
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
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
ca implique forcement d'avoir une distribution à base source (ou alors à avoir un repositery de quelques To), et ca c'est pas forcement tres pratique ni rapide ni écologique
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
maintenant meme les "vieux" noyaux les integrent mais maintenant on a uio)
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
niveaux de freeze aussi), mais il est vrai que seul debian a une branche stable (niveau bogues) avec une progression assez continue, sauf un an toutes les décenies (en gros)
ciol wrote:
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
lequel il est assez difficile d'évoluer sur le reste (ce que fait la
plupart des distributions en ce qui concerne gcc 4* en fait)
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
application casse» et «tout n'est pas mis à jour en même temps».
Si disons k3b casse (exemple totalement pris au pif), si les mises à jours
sont d'un coup ou progressivement, en quoi rythmbox (toujours completement
au pif) pourrait être touché d'une quelconque maniere (en supposant avoir
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
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
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
ca implique forcement d'avoir une distribution à base source (ou alors à
avoir un repositery de quelques To), et ca c'est pas forcement tres
pratique ni rapide ni écologique
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
maintenant meme les "vieux" noyaux les integrent mais maintenant on a uio)
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
niveaux de freeze aussi), mais il est vrai que seul debian a une branche
stable (niveau bogues) avec une progression assez continue, sauf un an
toutes les décenies (en gros)
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
lequel il est assez difficile d'évoluer sur le reste (ce que fait la plupart des distributions en ce qui concerne gcc 4* en fait)
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
application casse» et «tout n'est pas mis à jour en même temps». Si disons k3b casse (exemple totalement pris au pif), si les mises à jours sont d'un coup ou progressivement, en quoi rythmbox (toujours completement au pif) pourrait être touché d'une quelconque maniere (en supposant avoir
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
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
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
ca implique forcement d'avoir une distribution à base source (ou alors à avoir un repositery de quelques To), et ca c'est pas forcement tres pratique ni rapide ni écologique
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
maintenant meme les "vieux" noyaux les integrent mais maintenant on a uio)
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
niveaux de freeze aussi), mais il est vrai que seul debian a une branche stable (niveau bogues) avec une progression assez continue, sauf un an toutes les décenies (en gros)
ciol
Phh wrote:
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
On ne change pas de PC aussi souvent non plus. Dans mon idéal, xorg est changé tous les 6 mois (et la base tous les ans). Au pire, si une carte graphique n'est pas prise en compte pendant ces 6 mois : - prendre le driver vesa qui fonctionne tout le temps - ou prendre provisoirement la version 'current' de la distrib, ou changer de distrib
(et puis, ton raisonnement s'applique aussi pour des distributions comme Ubuntu. C'est juste qu'il ne faut pas penser en binaire, mais savoir faire des compromis (ce que les distributions actuelles ne font pas)).
Phh wrote:
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
On ne change pas de PC aussi souvent non plus.
Dans mon idéal, xorg est changé tous les 6 mois (et la base tous les ans).
Au pire, si une carte graphique n'est pas prise en compte pendant ces 6
mois :
- prendre le driver vesa qui fonctionne tout le temps
- ou prendre provisoirement la version 'current' de la distrib, ou
changer de distrib
(et puis, ton raisonnement s'applique aussi pour des distributions comme
Ubuntu. C'est juste qu'il ne faut pas penser en binaire, mais savoir
faire des compromis (ce que les distributions actuelles ne font pas)).
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
On ne change pas de PC aussi souvent non plus. Dans mon idéal, xorg est changé tous les 6 mois (et la base tous les ans). Au pire, si une carte graphique n'est pas prise en compte pendant ces 6 mois : - prendre le driver vesa qui fonctionne tout le temps - ou prendre provisoirement la version 'current' de la distrib, ou changer de distrib
(et puis, ton raisonnement s'applique aussi pour des distributions comme Ubuntu. C'est juste qu'il ne faut pas penser en binaire, mais savoir faire des compromis (ce que les distributions actuelles ne font pas)).
