# La mise à niveau a échoué de manière spectaculaire **URL:** \ **Category:** Product Support\ **Created:** [Février 6, 2025, 1:09 UTC](https://meta.discourse.org/t/upgrade-failed-spectacularily/350773 "2025-02-06T01:09:07Z")\ **Posts on this page:** 1\ **Showing post:** 39
**Author:** ![Heliosurge](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/heliosurge/32/571810_2.png) [@Heliosurge](https://meta.discourse.org/u/Heliosurge)\ **Post date:** [Février 10, 2025, 11:51 UTC](https://meta.discourse.org/t/upgrade-failed-spectacularily/350773/39 "2025-02-10T23:51:55Z")
Il y a certainement des opportunités ici pour améliorer Discourse. Ayant une instance Stable en fonctionnement depuis maintenant 7 à 8 ans, il y a toujours eu des moments où j’ai dû faire une mise à jour via la ligne de commande du serveur. Cela est même couvert dans la documentation avec une fréquence recommandée. Cependant, la documentation n’est pas aussi facile d’accès qu’elle pourrait l’être. Le plugin de catégories de documents est certainement une amélioration. Mais toujours, à mon humble avis, pas aussi bon qu’il pourrait l’être. Mes recommandations pour l’améliorer seraient d’avoir des liens directement dans l’interface web d’administration. Peut-être avec un lien (?) pour faire apparaître une pop-up avec quelques infos et un lien vers un sujet ici sur Meta avec des infos plus détaillées. Avec le panneau de mise à jour, il serait utile d’avoir aussi des informations supplémentaires de la même manière, même avec Core & Docker, pour griser le bouton avec un message indiquant qu’il faut faire la mise à jour depuis la ligne de commande du serveur, avec un lien vers les notes de version de cette release spécifique, avec la première section détaillant les exigences, par exemple Docker Version X et Ubuntu LTS version X (ou distributions Linux officielles supportées équivalentes). Le sujet lié devrait selon moi aussi inclure des éléments pour copier-coller en ligne de commande du serveur. Concernant les scripts, je ne sais pas combien cela pourrait être facile à faire. Mais faire en sorte que le script initial vérifie certaines exigences de base. Si une dépendance requise n’est pas présente, il doit sortir avec un message et peut-être un lien vers les informations de base nécessaires. Le message d’échec de la mise à jour doit être plus intuitif. Bien qu’il indique de faire défiler vers le haut pour voir les erreurs précédentes, j’ai constaté qu’il y a des erreurs qui semblent communes et qui n’affectent pas la reconstruction. Exporter les erreurs clés dans un fichier journal qui a causé l’échec de la reconstruction serait bien meilleur. Toutefois, ces changements proposés nécessiteront probablement beaucoup de travail et de temps. Avec #Documentation > Self-Hosting, il faut vraiment un guide plus complet pour commencer, avec une introduction sur ce qu’il faut savoir avant de s’auto-héberger. Comme une bonne connaissance du système d’exploitation, comme Ubuntu LTS, avec quelques infos de base sur la maintenance et la mise à niveau de la distribution. Les meilleures pratiques pour les sauvegardes et des tutoriels directs. Ces informations pourraient même être ajoutées en tant que sujet avec des tags dans la catégorie Staff, avec des liens vers Meta. Bloomberg, si je me souviens bien, a réalisé un bon sujet sur ce qui s’est passé dans ce sujet. Pour ma part, je m’excuse auprès de @anon55243134. Cependant, ils doivent aussi prendre en charge leur propre partie. Si vous cherchez du support, il faut être prêt à écouter ce qui est dit et fournir les informations demandées pour que tous ceux qui le peuvent puissent aider à guider vers des solutions possibles. Nous pouvons tous avoir des idées ou des opinions sur comment le design, etc., pourrait être meilleur. Mais en attendant les changements que nous aimerions voir, nous devons accepter la situation actuelle. Je sais à quel point il est déconcertant d’avoir des temps d’arrêt nuisibles. Il y a quelque temps, j’ai eu un problème avec le client pour lequel je suis bénévole en tant qu’administrateur. Je leur ai fait une pétition pendant plus d’un mois lorsque je ne pouvais pas reconstruire l’application à cause d’un serveur trop petit, et les instructions pour libérer de l’espace ici n’ont pas permis de résoudre le problème, ils ont ignoré mon conseil et finalement, comme je l’avais prévu, le serveur a subi une panne majeure. Ils ont fini par payer un membre ici pour réparer le problème, ce qui a impliqué le déploiement d’un nouveau serveur avec suffisamment d’espace. Le site a été en panne pendant plus de 2 semaines à cause de leur négligence. Plus tard, ils ne géraient pas la maintenance du serveur de messagerie et alors que le site n’était pas en panne, l’absence d’e-mails de notification a causé beaucoup de dégâts. Je pourrais en dire plus. Mais ce n’est pas un problème de Discourse. C’est un problème d’hébergement autonome. Il y a longtemps, j’ai rencontré un problème de reconstruction causé par un fichier modèle. Le journal m’a donné suffisamment d’indices pour explorer une hypothèse selon laquelle en commentant le fichier modèle, cela aurait résolu mon problème. Quand je suis venu ici, j’ai posté ce que j’avais fait, ce qui a aidé à identifier le problème pour l’équipe. De tous côtés, nous devons nous efforcer de nous améliorer. Prenez le temps de lire et d’écouter ceux qui ont de l’expérience et des compétences pour aider à résoudre les problèmes. C’est ainsi que j’ai acquis ma conscience des choses que je peux faire. Pour les domaines (particulièrement avec la complexité de Discourse) pour lesquels je ne suis pas expérimenté, je fais des recherches autant que possible, je demande de l’aide et je prends en compte les conseils de tous ceux ici qui maîtrisent davantage ce logiciel fantastique. @anon55243134, si tu es prêt à donner sa chance aux choses, peut-être que nous pourrons tous t’aider à revenir en ligne. Il faut simplement éviter pendant ce processus de dévier vers « comment on pense que ça devrait être » et accepter pour le moment « comment c’est ». Une fois tout réparé, nous pourrons tirer des leçons et commencer une bonne discussion avec des recommandations pour améliorer les choses, et accepter, si l’équipe est réceptive (ce qui est généralement le cas), que cela prendra un certain temps, car d’autres projets sont en cours. De notre côté, nous pouvons travailler sur des idées, et ceux qui ont de véritables connaissances peuvent, s’ils ont du temps, travailler sur certaines des informations nécessaires pour les instructions, les meilleures pratiques, etc. --- _[View the full topic](https://meta.discourse.org/t/upgrade-failed-spectacularily/350773)._