Mais qui en substance a dit =E7a (j'ai modifi=E9 les mots pour que vous ne
googlisiez trop facilement :-), mais l'id=E9e y est) :
"C'est beaucoup plus facile de diffuser un soft qui puisse tourner sur
les diff=E9rentes versions de Windows (depuis XP) que d'en packager un
qui puisse s'installer et tourner sur les quelques distributions Linux
majeures du moment (sans m=EAme parler des versions ant=E9rieures de ces
distributions)"
C'est sûr que distribuer un soft pour M tout-le-monde en lui disant qu'il faut le compiler (ainsi que les bibliothèques utilisées), ça le fait vachement.
C'est sur que distribuer du soft pour M tout-le-monde sous Linux, OS utilisé par 1% de la population au mieux, c'est pas non plus un tres tres grand départ.
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
-- pehache http://pehache.free.fr
"ST" <st@unices.org> a écrit dans le message de news:
ck4j28-4h41.ln1@gulliver.unices.org
On 2/12/11 8:20 PM, pehache-youplaboum wrote:
C'est sûr que distribuer un soft pour M tout-le-monde en lui disant
qu'il faut le compiler (ainsi que les bibliothèques utilisées), ça le
fait vachement.
C'est sur que distribuer du soft pour M tout-le-monde sous Linux, OS
utilisé par 1% de la population au mieux, c'est pas non plus un tres
tres grand départ.
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
C'est sûr que distribuer un soft pour M tout-le-monde en lui disant qu'il faut le compiler (ainsi que les bibliothèques utilisées), ça le fait vachement.
C'est sur que distribuer du soft pour M tout-le-monde sous Linux, OS utilisé par 1% de la population au mieux, c'est pas non plus un tres tres grand départ.
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
-- pehache http://pehache.free.fr
Aeris
pehache-youplaboum wrote:
"stable" du point de vue du packageur d'une distrib ne veut pas forcément pas dire la même chose que "stable" du point de vue de l'auteur de l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un paquet marqué stable par la QA de Debian que par les dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de personnes et cela correspond réellement à une absence de bugs bloquants et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son fichier codé avec les pieds…
pehache-youplaboum wrote:
"stable" du point de vue du packageur d'une distrib ne veut pas forcément
pas dire la même chose que "stable" du point de vue de l'auteur de
l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un
paquet marqué stable par la QA de Debian que par les dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de
personnes et cela correspond réellement à une absence de bugs bloquants
et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son
fichier codé avec les pieds…
"stable" du point de vue du packageur d'une distrib ne veut pas forcément pas dire la même chose que "stable" du point de vue de l'auteur de l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un paquet marqué stable par la QA de Debian que par les dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de personnes et cela correspond réellement à une absence de bugs bloquants et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son fichier codé avec les pieds…
ST
On 2/13/11 4:24 AM, pehache-youplaboum wrote:
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
C'est assez contradictoire comme point de vue. Qui dit LL dit obligatoirement bcp de versions d'une même chose. On ne peut pas promouvoir le LL et critiquer en meme temps un des principes de base du LL.
-- http://www.unices.org
On 2/13/11 4:24 AM, pehache-youplaboum wrote:
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
C'est assez contradictoire comme point de vue. Qui dit LL dit
obligatoirement bcp de versions d'une même chose. On ne peut pas
promouvoir le LL et critiquer en meme temps un des principes de base du LL.
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
C'est assez contradictoire comme point de vue. Qui dit LL dit obligatoirement bcp de versions d'une même chose. On ne peut pas promouvoir le LL et critiquer en meme temps un des principes de base du LL.
-- http://www.unices.org
ST
On 2/13/11 9:19 AM, Aeris wrote:
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un paquet marqué stable par la QA de Debian que par les dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de personnes et cela correspond réellement à une absence de bugs bloquants et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son fichier codé avec les pieds…
Non, puis si jamais le logiciels ne comporte pas de bug, les patch appliqués par Debian se chargent d'en rajouter à la place. Au strict minimum, ils utilisent une procédure d'installation qui invalide la documentation d'origine la plupart du temps.
-- http://www.unices.org
On 2/13/11 9:19 AM, Aeris wrote:
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un
paquet marqué stable par la QA de Debian que par les dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de
personnes et cela correspond réellement à une absence de bugs bloquants
et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son
fichier codé avec les pieds…
Non, puis si jamais le logiciels ne comporte pas de bug, les patch
appliqués par Debian se chargent d'en rajouter à la place. Au strict
minimum, ils utilisent une procédure d'installation qui invalide la
documentation d'origine la plupart du temps.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un paquet marqué stable par la QA de Debian que par les dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de personnes et cela correspond réellement à une absence de bugs bloquants et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son fichier codé avec les pieds…
Non, puis si jamais le logiciels ne comporte pas de bug, les patch appliqués par Debian se chargent d'en rajouter à la place. Au strict minimum, ils utilisent une procédure d'installation qui invalide la documentation d'origine la plupart du temps.
-- http://www.unices.org
Jerome Lambert
Le 13/02/11 02:19, Aeris a écrit :
pehache-youplaboum wrote:
"stable" du point de vue du packageur d'une distrib ne veut pas forcément pas dire la même chose que "stable" du point de vue de l'auteur de l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un paquet marqué stable par la QA de Debian que par les dires de son auteur.
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait où en est son programme.
Le 13/02/11 02:19, Aeris a écrit :
pehache-youplaboum wrote:
"stable" du point de vue du packageur d'une distrib ne veut pas forcément
pas dire la même chose que "stable" du point de vue de l'auteur de
l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un
paquet marqué stable par la QA de Debian que par les dires de son auteur.
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait où
en est son programme.
"stable" du point de vue du packageur d'une distrib ne veut pas forcément pas dire la même chose que "stable" du point de vue de l'auteur de l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un paquet marqué stable par la QA de Debian que par les dires de son auteur.
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait où en est son programme.
Aeris
Jerome Lambert wrote:
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait où en est son programme.
Oui et non
Certes, lui a déjà la capacité à dire que le soft est instable parce qu'il a eu des soucis chez lui et/ou des remontés de bugs de la part de ses beta- utilisateurs. Mais en aucun cas le fait d'avoir l'impression que son soft est stable sur SON poste et avec SON utilisation personnelle ne garanti que le soft est stable PARTOUT et pour TOUTE utilisation possible.
Le passage obligatoire par experimental->unstable->testing->stable, de par son utilisation par des milliers de personnes dans des milliers de contextes, assure une probabilité très proche de 100% d'avoir couvert l'intégralité du soft avant de pouvoir le déclarer comme stable.
Un développeur peut indiquer que son soft est instable car il a connaissance de bugs existants, mais c'est à la COMMUNAUTÉ de déclarer si le soft est stable ou non, pas à son auteur!
Jerome Lambert wrote:
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait où
en est son programme.
Oui et non
Certes, lui a déjà la capacité à dire que le soft est instable parce qu'il a
eu des soucis chez lui et/ou des remontés de bugs de la part de ses beta-
utilisateurs.
Mais en aucun cas le fait d'avoir l'impression que son soft est stable sur
SON poste et avec SON utilisation personnelle ne garanti que le soft est
stable PARTOUT et pour TOUTE utilisation possible.
Le passage obligatoire par experimental->unstable->testing->stable, de par
son utilisation par des milliers de personnes dans des milliers de
contextes, assure une probabilité très proche de 100% d'avoir couvert
l'intégralité du soft avant de pouvoir le déclarer comme stable.
Un développeur peut indiquer que son soft est instable car il a connaissance
de bugs existants, mais c'est à la COMMUNAUTÉ de déclarer si le soft est
stable ou non, pas à son auteur!
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait où en est son programme.
Oui et non
Certes, lui a déjà la capacité à dire que le soft est instable parce qu'il a eu des soucis chez lui et/ou des remontés de bugs de la part de ses beta- utilisateurs. Mais en aucun cas le fait d'avoir l'impression que son soft est stable sur SON poste et avec SON utilisation personnelle ne garanti que le soft est stable PARTOUT et pour TOUTE utilisation possible.
Le passage obligatoire par experimental->unstable->testing->stable, de par son utilisation par des milliers de personnes dans des milliers de contextes, assure une probabilité très proche de 100% d'avoir couvert l'intégralité du soft avant de pouvoir le déclarer comme stable.
Un développeur peut indiquer que son soft est instable car il a connaissance de bugs existants, mais c'est à la COMMUNAUTÉ de déclarer si le soft est stable ou non, pas à son auteur!
pehache-youplaboum
"ST" a écrit dans le message de news:
On 2/13/11 4:24 AM, pehache-youplaboum wrote:
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
C'est assez contradictoire comme point de vue. Qui dit LL dit obligatoirement bcp de versions d'une même chose.
Non, pas "obligatoirement". Il n'y a par exemple qu'un noyau Linux. Du moins pour l'instant.
On ne peut pas promouvoir le LL et critiquer en meme temps un des principes de base du LL.
Sauf qu'à certains moment la multiplicité pose des problèmes, et c'est précisément le cas ici.
-- pehache http://pehache.free.fr
"ST" <st@unices.org> a écrit dans le message de news:
2lgk28-q811.ln1@gulliver.unices.org
On 2/13/11 4:24 AM, pehache-youplaboum wrote:
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
C'est assez contradictoire comme point de vue. Qui dit LL dit
obligatoirement bcp de versions d'une même chose.
Non, pas "obligatoirement". Il n'y a par exemple qu'un noyau Linux. Du moins
pour l'instant.
On ne peut pas
promouvoir le LL et critiquer en meme temps un des principes de base
du LL.
Sauf qu'à certains moment la multiplicité pose des problèmes, et c'est
précisément le cas ici.
Chacun son truc. Lui c'est de promovoir le LL à travers Linux.
C'est assez contradictoire comme point de vue. Qui dit LL dit obligatoirement bcp de versions d'une même chose.
Non, pas "obligatoirement". Il n'y a par exemple qu'un noyau Linux. Du moins pour l'instant.
On ne peut pas promouvoir le LL et critiquer en meme temps un des principes de base du LL.
Sauf qu'à certains moment la multiplicité pose des problèmes, et c'est précisément le cas ici.
-- pehache http://pehache.free.fr
pehache-youplaboum
"Aeris" a écrit dans le message de news: 4d57319a$0$9246$
pehache-youplaboum wrote:
"stable" du point de vue du packageur d'une distrib ne veut pas forcément pas dire la même chose que "stable" du point de vue de l'auteur de l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un paquet marqué stable par la QA de Debian que par les dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de personnes et cela correspond réellement à une absence de bugs bloquants et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son fichier codé avec les pieds…
On sent tout le respect pour les auteurs de logiciels dans cette phrase :-)
A part ça tu persistes à ne pas comprendre que "stable" ne veut pas dire la même chose pour le packageur ou pour l'auteur.
Pour l'auteur, son appli est stable quand il a développé les fonctionnalités qu'il voulait, qu'elles sont opérationnelles, et qu'il n'y a plus trop de bugs intrinsèques.
Pour le packageur d'une distrib, une appli est stable quand elle est bien intégrée dans la distrib, qu'elle n'y fout pas le bazar, et qu'il n'y a pas trop de bugs spécifiques à l'intégration dans la distrib.
Ce sont deux points de vue TRES différents, et qui sont tous les deux valables. Mais ça veut bien dire que le packageur peut déclarer "stable" une version d'appli considérée comme "instable" par son auteur, parce qu'ils ne parlent pas de la même chose. Et c'est exactement le cas décrit dans le lien que j'ai indiqué.
-- pehache http://pehache.free.fr
"Aeris" <aeris@imirhil.fr> a écrit dans le message de news:
4d57319a$0$9246$426a74cc@news.free.fr
pehache-youplaboum wrote:
"stable" du point de vue du packageur d'une distrib ne veut pas
forcément pas dire la même chose que "stable" du point de vue de
l'auteur de l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus
confiance à un paquet marqué stable par la QA de Debian que par les
dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de
personnes et cela correspond réellement à une absence de bugs
bloquants et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son
fichier codé avec les pieds…
On sent tout le respect pour les auteurs de logiciels dans cette phrase :-)
A part ça tu persistes à ne pas comprendre que "stable" ne veut pas dire la
même chose pour le packageur ou pour l'auteur.
Pour l'auteur, son appli est stable quand il a développé les fonctionnalités
qu'il voulait, qu'elles sont opérationnelles, et qu'il n'y a plus trop de
bugs intrinsèques.
Pour le packageur d'une distrib, une appli est stable quand elle est bien
intégrée dans la distrib, qu'elle n'y fout pas le bazar, et qu'il n'y a pas
trop de bugs spécifiques à l'intégration dans la distrib.
Ce sont deux points de vue TRES différents, et qui sont tous les deux
valables. Mais ça veut bien dire que le packageur peut déclarer "stable" une
version d'appli considérée comme "instable" par son auteur, parce qu'ils ne
parlent pas de la même chose. Et c'est exactement le cas décrit dans le lien
que j'ai indiqué.
"Aeris" a écrit dans le message de news: 4d57319a$0$9246$
pehache-youplaboum wrote:
"stable" du point de vue du packageur d'une distrib ne veut pas forcément pas dire la même chose que "stable" du point de vue de l'auteur de l'appli.
Si on prend l'exemple de Debian, je fais quand même bien plus confiance à un paquet marqué stable par la QA de Debian que par les dires de son auteur.
Au moins le critère de stabilité a été vérifié par une multitude de personnes et cela correspond réellement à une absence de bugs bloquants et/ou majeurs sur l'application en question.
C'est pas juste un gars qui a foutu « -stable » à la fin du nom de son fichier codé avec les pieds…
On sent tout le respect pour les auteurs de logiciels dans cette phrase :-)
A part ça tu persistes à ne pas comprendre que "stable" ne veut pas dire la même chose pour le packageur ou pour l'auteur.
Pour l'auteur, son appli est stable quand il a développé les fonctionnalités qu'il voulait, qu'elles sont opérationnelles, et qu'il n'y a plus trop de bugs intrinsèques.
Pour le packageur d'une distrib, une appli est stable quand elle est bien intégrée dans la distrib, qu'elle n'y fout pas le bazar, et qu'il n'y a pas trop de bugs spécifiques à l'intégration dans la distrib.
Ce sont deux points de vue TRES différents, et qui sont tous les deux valables. Mais ça veut bien dire que le packageur peut déclarer "stable" une version d'appli considérée comme "instable" par son auteur, parce qu'ils ne parlent pas de la même chose. Et c'est exactement le cas décrit dans le lien que j'ai indiqué.
-- pehache http://pehache.free.fr
pehache-youplaboum
"Aeris" a écrit dans le message de news: 4d57da7c$0$10721$
Jerome Lambert wrote:
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait où en est son programme.
Oui et non
Certes, lui a déjà la capacité à dire que le soft est instable parce qu'il a eu des soucis chez lui et/ou des remontés de bugs de la part de ses beta- utilisateurs. Mais en aucun cas le fait d'avoir l'impression que son soft est stable sur SON poste et avec SON utilisation personnelle ne garanti que le soft est stable PARTOUT et pour TOUTE utilisation possible.
Le passage obligatoire par experimental->unstable->testing->stable, de par son utilisation par des milliers de personnes dans des milliers de contextes, assure une probabilité très proche de 100% d'avoir couvert l'intégralité du soft avant de pouvoir le déclarer comme stable.
Un développeur peut indiquer que son soft est instable car il a connaissance de bugs existants, mais c'est à la COMMUNAUTÉ de déclarer si le soft est stable ou non, pas à son auteur!
Là tu es en plein dans la théorie.
Pour la pratique, va voir les rapports de bugs d'une distrib ou d'une autre : il que les des rapports de bugs soient fermés sans action corrective parce que ce sont des bugs "upstream", c'est à dire qui sont dans les applis elles-mêmes et non pas relatifs à leur intégration dans la distrib.
Il faudrait donc que l'auteur suive les rapports de bugs de chaque distro pour être sûr d'être au courant de ce que la communauté remonte. Très pratique. Et en plus ça lui fait une belle jambe si les bugs remontés concernent une version qui n'est plus maintenue par lui, parce que c'est celle qui est dans la distrib, alors que lui en est déjà à une version n+1 ou n+2. Tout ça est adapté à des méga-projets genre OOo, qui ont du monde et qui ont plusieurs branches de dév en parallèle, mais pas à des petits projets, ni même moyens (Gcompris n'est pas un petit projet, mais pas non plus un mega-projet avec pléthore de développeurs j'imagine).
-- pehache http://pehache.free.fr
"Aeris" <aeris@imirhil.fr> a écrit dans le message de news:
4d57da7c$0$10721$426a34cc@news.free.fr
Jerome Lambert wrote:
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait
où en est son programme.
Oui et non
Certes, lui a déjà la capacité à dire que le soft est instable parce
qu'il a eu des soucis chez lui et/ou des remontés de bugs de la part
de ses beta- utilisateurs.
Mais en aucun cas le fait d'avoir l'impression que son soft est
stable sur SON poste et avec SON utilisation personnelle ne garanti
que le soft est stable PARTOUT et pour TOUTE utilisation possible.
Le passage obligatoire par experimental->unstable->testing->stable,
de par son utilisation par des milliers de personnes dans des
milliers de contextes, assure une probabilité très proche de 100%
d'avoir couvert l'intégralité du soft avant de pouvoir le déclarer
comme stable.
Un développeur peut indiquer que son soft est instable car il a
connaissance de bugs existants, mais c'est à la COMMUNAUTÉ de
déclarer si le soft est stable ou non, pas à son auteur!
Là tu es en plein dans la théorie.
Pour la pratique, va voir les rapports de bugs d'une distrib ou d'une autre
: il que les des rapports de bugs soient fermés sans action corrective parce
que ce sont des bugs "upstream", c'est à dire qui sont dans les applis
elles-mêmes et non pas relatifs à leur intégration dans la distrib.
Il faudrait donc que l'auteur suive les rapports de bugs de chaque distro
pour être sûr d'être au courant de ce que la communauté remonte. Très
pratique. Et en plus ça lui fait une belle jambe si les bugs remontés
concernent une version qui n'est plus maintenue par lui, parce que c'est
celle qui est dans la distrib, alors que lui en est déjà à une version n+1
ou n+2. Tout ça est adapté à des méga-projets genre OOo, qui ont du monde et
qui ont plusieurs branches de dév en parallèle, mais pas à des petits
projets, ni même moyens (Gcompris n'est pas un petit projet, mais pas non
plus un mega-projet avec pléthore de développeurs j'imagine).
"Aeris" a écrit dans le message de news: 4d57da7c$0$10721$
Jerome Lambert wrote:
Et bien moi c'est le contraire: il n'y a amha que l'auteur qui sait où en est son programme.
Oui et non
Certes, lui a déjà la capacité à dire que le soft est instable parce qu'il a eu des soucis chez lui et/ou des remontés de bugs de la part de ses beta- utilisateurs. Mais en aucun cas le fait d'avoir l'impression que son soft est stable sur SON poste et avec SON utilisation personnelle ne garanti que le soft est stable PARTOUT et pour TOUTE utilisation possible.
Le passage obligatoire par experimental->unstable->testing->stable, de par son utilisation par des milliers de personnes dans des milliers de contextes, assure une probabilité très proche de 100% d'avoir couvert l'intégralité du soft avant de pouvoir le déclarer comme stable.
Un développeur peut indiquer que son soft est instable car il a connaissance de bugs existants, mais c'est à la COMMUNAUTÉ de déclarer si le soft est stable ou non, pas à son auteur!
Là tu es en plein dans la théorie.
Pour la pratique, va voir les rapports de bugs d'une distrib ou d'une autre : il que les des rapports de bugs soient fermés sans action corrective parce que ce sont des bugs "upstream", c'est à dire qui sont dans les applis elles-mêmes et non pas relatifs à leur intégration dans la distrib.
Il faudrait donc que l'auteur suive les rapports de bugs de chaque distro pour être sûr d'être au courant de ce que la communauté remonte. Très pratique. Et en plus ça lui fait une belle jambe si les bugs remontés concernent une version qui n'est plus maintenue par lui, parce que c'est celle qui est dans la distrib, alors que lui en est déjà à une version n+1 ou n+2. Tout ça est adapté à des méga-projets genre OOo, qui ont du monde et qui ont plusieurs branches de dév en parallèle, mais pas à des petits projets, ni même moyens (Gcompris n'est pas un petit projet, mais pas non plus un mega-projet avec pléthore de développeurs j'imagine).
-- pehache http://pehache.free.fr
Aeris
pehache-youplaboum wrote:
On sent tout le respect pour les auteurs de logiciels dans cette phrase :-)
Tout à fait Je respecte totalement les développeurs, étant donné que j'en suis un moi- même et que j'en vis. Mais pour travailler dans ce milieu, je peux vous dire qu'une grande majorité des « développeurs » a du avoir son diplôme dans une pochette surprise… Et bizarrement la proportion est très souvent inversement proportionnelle à l'attitude libriste et open-source du développeur…
A part ça tu persistes à ne pas comprendre que "stable" ne veut pas dire la même chose pour le packageur ou pour l'auteur.
Pour l'auteur, son appli est stable quand il a développé les fonctionnalités qu'il voulait, qu'elles sont opérationnelles, et qu'il n'y a plus trop de bugs intrinsèques.
Toutes les fonctionnalités = soft abouti et non pas stable, nuance Un soft peut être stable mais incomplet.
Et plus *trop* de bugs, ça veut dire stable chez toi? Moi j'appelle ça unstable ou testing à la limite, mais sûrement pas stable.
Et sur quoi l'auteur s'appuie pour dire qu'il n'y a pas de bugs? Son utilisation personnelle sur son unique PC maison (qui contient en prime son environnement de dev…)? On ne doit pas avoir la même notion de stabilité…
Pour le packageur d'une distrib, une appli est stable quand elle est bien intégrée dans la distrib, qu'elle n'y fout pas le bazar, et qu'il n'y a pas trop de bugs spécifiques à l'intégration dans la distrib.
C'est pas du tout ça, en tout cas chez Debian. Une appli y est indiquée « stable » lorsque: — toutes ses dépendances sont elles-aussi stables (on l'oublie beaucoup ce point-là…) — qu'il n'y a plus un seul bug bloquant ou majeur d'ouvert dans le bugtracker
Ce sont deux points de vue TRES différents, et qui sont tous les deux valables. Mais ça veut bien dire que le packageur peut déclarer "stable" une version d'appli considérée comme "instable" par son auteur, parce qu'ils ne parlent pas de la même chose.
On peut tout à fait faire ceci puisque justement l'avis de l'auteur n'a pas à être pris en compte, ni dans un sens ni dans l'autre. C'est bien la communauté et uniquement elle qui peut décréter qu'un soft est stable (ie utilisable en production, vendable à un client dans une solution logicielle, potentiellement couverte par une garantie constructeur sans risque financier…).
Après c'est sûr que si l'auteur lui-même déclare le soft instable, ça risque d'être difficile de le vendre comme stable à tes propres utilisateurs…
pehache-youplaboum wrote:
On sent tout le respect pour les auteurs de logiciels dans cette phrase
:-)
Tout à fait
Je respecte totalement les développeurs, étant donné que j'en suis un moi-
même et que j'en vis.
Mais pour travailler dans ce milieu, je peux vous dire qu'une grande
majorité des « développeurs » a du avoir son diplôme dans une pochette
surprise… Et bizarrement la proportion est très souvent inversement
proportionnelle à l'attitude libriste et open-source du développeur…
A part ça tu persistes à ne pas comprendre que "stable" ne veut pas dire
la même chose pour le packageur ou pour l'auteur.
Pour l'auteur, son appli est stable quand il a développé les
fonctionnalités qu'il voulait, qu'elles sont opérationnelles, et qu'il n'y
a plus trop de bugs intrinsèques.
Toutes les fonctionnalités = soft abouti et non pas stable, nuance
Un soft peut être stable mais incomplet.
Et plus *trop* de bugs, ça veut dire stable chez toi?
Moi j'appelle ça unstable ou testing à la limite, mais sûrement pas stable.
Et sur quoi l'auteur s'appuie pour dire qu'il n'y a pas de bugs?
Son utilisation personnelle sur son unique PC maison (qui contient en prime
son environnement de dev…)?
On ne doit pas avoir la même notion de stabilité…
Pour le packageur d'une distrib, une appli est stable quand elle est bien
intégrée dans la distrib, qu'elle n'y fout pas le bazar, et qu'il n'y a
pas trop de bugs spécifiques à l'intégration dans la distrib.
C'est pas du tout ça, en tout cas chez Debian.
Une appli y est indiquée « stable » lorsque:
— toutes ses dépendances sont elles-aussi stables (on l'oublie beaucoup ce
point-là…)
— qu'il n'y a plus un seul bug bloquant ou majeur d'ouvert dans le
bugtracker
Ce sont deux points de vue TRES différents, et qui sont tous les deux
valables. Mais ça veut bien dire que le packageur peut déclarer "stable"
une version d'appli considérée comme "instable" par son auteur, parce
qu'ils ne parlent pas de la même chose.
On peut tout à fait faire ceci puisque justement l'avis de l'auteur n'a pas
à être pris en compte, ni dans un sens ni dans l'autre.
C'est bien la communauté et uniquement elle qui peut décréter qu'un soft est
stable (ie utilisable en production, vendable à un client dans une solution
logicielle, potentiellement couverte par une garantie constructeur sans
risque financier…).
Après c'est sûr que si l'auteur lui-même déclare le soft instable, ça risque
d'être difficile de le vendre comme stable à tes propres utilisateurs…
On sent tout le respect pour les auteurs de logiciels dans cette phrase :-)
Tout à fait Je respecte totalement les développeurs, étant donné que j'en suis un moi- même et que j'en vis. Mais pour travailler dans ce milieu, je peux vous dire qu'une grande majorité des « développeurs » a du avoir son diplôme dans une pochette surprise… Et bizarrement la proportion est très souvent inversement proportionnelle à l'attitude libriste et open-source du développeur…
A part ça tu persistes à ne pas comprendre que "stable" ne veut pas dire la même chose pour le packageur ou pour l'auteur.
Pour l'auteur, son appli est stable quand il a développé les fonctionnalités qu'il voulait, qu'elles sont opérationnelles, et qu'il n'y a plus trop de bugs intrinsèques.
Toutes les fonctionnalités = soft abouti et non pas stable, nuance Un soft peut être stable mais incomplet.
Et plus *trop* de bugs, ça veut dire stable chez toi? Moi j'appelle ça unstable ou testing à la limite, mais sûrement pas stable.
Et sur quoi l'auteur s'appuie pour dire qu'il n'y a pas de bugs? Son utilisation personnelle sur son unique PC maison (qui contient en prime son environnement de dev…)? On ne doit pas avoir la même notion de stabilité…
Pour le packageur d'une distrib, une appli est stable quand elle est bien intégrée dans la distrib, qu'elle n'y fout pas le bazar, et qu'il n'y a pas trop de bugs spécifiques à l'intégration dans la distrib.
C'est pas du tout ça, en tout cas chez Debian. Une appli y est indiquée « stable » lorsque: — toutes ses dépendances sont elles-aussi stables (on l'oublie beaucoup ce point-là…) — qu'il n'y a plus un seul bug bloquant ou majeur d'ouvert dans le bugtracker
Ce sont deux points de vue TRES différents, et qui sont tous les deux valables. Mais ça veut bien dire que le packageur peut déclarer "stable" une version d'appli considérée comme "instable" par son auteur, parce qu'ils ne parlent pas de la même chose.
On peut tout à fait faire ceci puisque justement l'avis de l'auteur n'a pas à être pris en compte, ni dans un sens ni dans l'autre. C'est bien la communauté et uniquement elle qui peut décréter qu'un soft est stable (ie utilisable en production, vendable à un client dans une solution logicielle, potentiellement couverte par une garantie constructeur sans risque financier…).
Après c'est sûr que si l'auteur lui-même déclare le soft instable, ça risque d'être difficile de le vendre comme stable à tes propres utilisateurs…
