Personne n'oblige les developpeurs d'Asahi de publier leurs branches les plus expérimentales sur internet non plus hein. Git c'est décentralisé. Ce n'est pas comme si ils ne peuvent pas avoir une QA avec un passage en branche publique uniquement quand le code a été sujet à des tests sur les plateformes hardware supportées.
Réponse pré-existante :
"It discourages developers from working on new features publicly, something we care about a lot in the Free and Open Source Software community. It also frustrates developers, and in some cases, causes developers to stop supporting a distribution altogether. In this scenario, the end user gets the worst of both worlds: a broken distribution and developers who are unwilling to help."
« Cela décourage les développeurs de travailler publiquement sur de nouvelles fonctionnalités, ce qui nous tiens à cœur dans la communauté des logiciels libres et open source. Cela frustre également les développeurs et, dans certains cas, les amène à cesser complètement de soutenir une distribution. Dans ce scénario, l'utilisateur final subit le pire des deux mondes : une distribution cassée et des développeurs qui ne sont pas disposés à aider.
Là tu prends la posture du saboteur pour le seul bénéfice de gagner un débat sur un forum Internet.
Tu crois que toutes les distros envoient un mail au développeur de chaque bout de code, librairie, petit utilitaire avant de fournir un paquet? Tu crois que c'est une méthode de fonctionnement valable? Moi je serais le dev de la lib trucumuche, ça me gaverait de recevoir 50 emails de ce genre.
Réponse pré-existante :
"In short: when a project is being actively developed, tagged releases are the only safe option to ship to users."
« En bref, lorsqu'un projet est en cours de développement actif, les versions taggées sont la seule option sûre pour la distribution aux utilisateurs. »
Bienvenue à l’homme de paille. C’est toi qui prétends qu’il n’y a pas de graduation dans le traitement du code des autres.
Pas besoin de contacter un développeur si c’est clairement marqué comme prêt pour la publication. On parle ici de code en cours de développement dont une bonne partie relève probablement de l’essai & erreur.
Tu remarqueras qu’ils ne disent pas « la seule option », mais « la seule option sûre », c’est à dire l’option qui peut-être choisie les yeux fermé et donc sans interaction. Si tu sors des pistes, bien sûr t’es libre, mais tu peux te mettre à risque ou mettre les autres à risque, c’est mieux de s’y initier avec quelqu’un d’expérimenté dans le hors piste et dans ce terrain en particulier. Surtout qu’ils sont probablement disposés à aider, et peut-être même enthousiastes à cette idée.
Mais au final tu démontres précisément ce que je relevais : tu ne fais aucune différence entre un code en cours de rédaction et un code vérifié, relu, revu, validé, committé, releasé.
Sachant que même un code en cours de rédaction a plusieurs niveau, ça peut-être un code qui suit une documentation adaptée, qui réécrit un code existant et éprouvé, ou qui, comme ici, explore un terrain qu’aucune personne ne peut témoigner avoir exploré avant.
Comme je disais : C’est un variante de « si c’est sur Internet c’est pour être utilisé » : « si c’est sur Internet c’est que c’est prêt pour la production ».
Si tu supposes qu’il n’y a pas de différence et que tout code publié est distribuable, cela dit que tout code publié est prêt pour la production, et donc que tout code publié doit être prêt pour la production, cela interdit toute collaboration sur une forge publique, et on en revient au sabotage car il s’agit ici de poser des exigences qui font obstacle à l’effort de production.
Moi aussi, mais je préfère qu'ils ne pleurnichent pas si leur ego est blessé parce que quelqu'un a l'audace de l'utiliser et qu'ils ravalent leur fierté. Et s'ils n'en sont pas capables ils savent quoi faire.
Bienvenue à l’homme de paille. C’est toi qui supposes que c’est une affaire d’égo.
Ça s’appelle rationaliser une posture pré-éxistante, c’est précisément ce dont je parle dans mon commentaire précédent. Celui qui ne fait pas l’effort de communiquer avec l’amont quand c’est nécessaire ou qui défend ce genre de déséquilibre doit appaiser sa tension interne et pour se faire il doit se persuader qu’il y a une bonne raison qui empêche de le faire ou qui justifie de ne pas le faire.
Le plus simple pour cela est de calomnier comme tu viens précisément de le faire. Tu prétends que ce sont des pleurnichards égoïstes imbus de fierté, ce faisant tu persuades les autres et te persuades que toute communication avec eux sera difficile et douloureuse et qu’ils rendent les relation sociale difficile si ce n’est qu’ils s’y opposent, et donc cela justifie de ne pas communiquer avec eux ou même qu’au final, ils sont la cause de toute absence de communication car il faut bien se protéger des gens toxiques. Distribuer leur code dans ces conditions et selon ces manières serait même un acte héroïque qui permettrait de sauver cette production de la main de ces gens problématiques, c’est être une forme de robin des bois des temps modernes qui prend aux méchants pour donner aux gentils.
Quod erat demonstrandum.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: twit ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal ManjaroARM se fait épingler par Asahi Linux. Évalué à 10. Dernière modification le 04 octobre 2022 à 13:12.
J’ai lié ça, je vais en citer des bouts : https://dont-ship.it/
Réponse pré-existante :
"It discourages developers from working on new features publicly, something we care about a lot in the Free and Open Source Software community. It also frustrates developers, and in some cases, causes developers to stop supporting a distribution altogether. In this scenario, the end user gets the worst of both worlds: a broken distribution and developers who are unwilling to help."
« Cela décourage les développeurs de travailler publiquement sur de nouvelles fonctionnalités, ce qui nous tiens à cœur dans la communauté des logiciels libres et open source. Cela frustre également les développeurs et, dans certains cas, les amène à cesser complètement de soutenir une distribution. Dans ce scénario, l'utilisateur final subit le pire des deux mondes : une distribution cassée et des développeurs qui ne sont pas disposés à aider.
Là tu prends la posture du saboteur pour le seul bénéfice de gagner un débat sur un forum Internet.
Réponse pré-existante :
"In short: when a project is being actively developed, tagged releases are the only safe option to ship to users."
« En bref, lorsqu'un projet est en cours de développement actif, les versions taggées sont la seule option sûre pour la distribution aux utilisateurs. »
Bienvenue à l’homme de paille. C’est toi qui prétends qu’il n’y a pas de graduation dans le traitement du code des autres.
Pas besoin de contacter un développeur si c’est clairement marqué comme prêt pour la publication. On parle ici de code en cours de développement dont une bonne partie relève probablement de l’essai & erreur.
Tu remarqueras qu’ils ne disent pas « la seule option », mais « la seule option sûre », c’est à dire l’option qui peut-être choisie les yeux fermé et donc sans interaction. Si tu sors des pistes, bien sûr t’es libre, mais tu peux te mettre à risque ou mettre les autres à risque, c’est mieux de s’y initier avec quelqu’un d’expérimenté dans le hors piste et dans ce terrain en particulier. Surtout qu’ils sont probablement disposés à aider, et peut-être même enthousiastes à cette idée.
Mais au final tu démontres précisément ce que je relevais : tu ne fais aucune différence entre un code en cours de rédaction et un code vérifié, relu, revu, validé, committé, releasé.
Sachant que même un code en cours de rédaction a plusieurs niveau, ça peut-être un code qui suit une documentation adaptée, qui réécrit un code existant et éprouvé, ou qui, comme ici, explore un terrain qu’aucune personne ne peut témoigner avoir exploré avant.
Comme je disais : C’est un variante de « si c’est sur Internet c’est pour être utilisé » : « si c’est sur Internet c’est que c’est prêt pour la production ».
Si tu supposes qu’il n’y a pas de différence et que tout code publié est distribuable, cela dit que tout code publié est prêt pour la production, et donc que tout code publié doit être prêt pour la production, cela interdit toute collaboration sur une forge publique, et on en revient au sabotage car il s’agit ici de poser des exigences qui font obstacle à l’effort de production.
Bienvenue à l’homme de paille. C’est toi qui supposes que c’est une affaire d’égo.
Ça s’appelle rationaliser une posture pré-éxistante, c’est précisément ce dont je parle dans mon commentaire précédent. Celui qui ne fait pas l’effort de communiquer avec l’amont quand c’est nécessaire ou qui défend ce genre de déséquilibre doit appaiser sa tension interne et pour se faire il doit se persuader qu’il y a une bonne raison qui empêche de le faire ou qui justifie de ne pas le faire.
Le plus simple pour cela est de calomnier comme tu viens précisément de le faire. Tu prétends que ce sont des pleurnichards égoïstes imbus de fierté, ce faisant tu persuades les autres et te persuades que toute communication avec eux sera difficile et douloureuse et qu’ils rendent les relation sociale difficile si ce n’est qu’ils s’y opposent, et donc cela justifie de ne pas communiquer avec eux ou même qu’au final, ils sont la cause de toute absence de communication car il faut bien se protéger des gens toxiques. Distribuer leur code dans ces conditions et selon ces manières serait même un acte héroïque qui permettrait de sauver cette production de la main de ces gens problématiques, c’est être une forme de robin des bois des temps modernes qui prend aux méchants pour donner aux gentils.
Quod erat demonstrandum.
ce commentaire est sous licence cc by 4 et précédentes