Très "customizable", en particulier la gestion des tickets ("issues"), pour l'adapter à la méthode de gestion des bugs (par exemple, ajout de champs "Contexte", "problème constaté", "résultat attendu", etc). + possibilité de hiérarchiser les tickets.
Au passage, lien faciles dans tous les sens, entre les tickets, le Wiki intégré et les commit dans les repo lié au projet.
Avec par exemple, des liens ticket --> commit, mais aussi commentaire de commit --> ticket(s) concerné(s).
Fun fact (comme disent les djeunz !) : pas au top quand il s'agit d'extraire une liste de tickets, avec les commentaires et images jointes. Du coup, je m'étais fait un utilitaire qui parcourait la database Redmine, permettait de filtrer et de générer une page Web. Ensuite, c'était facile à transformer en PDF, pour l'envoyer à un fournisseur par exemple, si on ne veut pas lui donner un compte Redmine.
Faudra que j'essaye de passer par le tgz, parce que là, après quelques mois d'inutilisation, je constate que mon Redmine perso est cassé, et les logs ne sont pas mes amis pour comprendre d'où ça vient …
La première fois que je l'ai utilisé, c'était après une petite étude des outils du domaine. Je me rappelle vaguement Trac, pas les autres.
Malgré les bémols qui suivent, j'ai choisi Redmine parce que plus simple à installer et auto-héberger (chez OVH ou à la maison).
Redmine
Petit retour d'expérience sur Redmine, par un type qui est carrément plus codeur qu'adminsys, mais qui s'est retrouvé à gérer de tels outils, au taf ou pour lui-même.
TL;DR : je déconseille s'il faut le garder à jour en permanence. Sauf à être nettement plus versé que moi dans l'admin.
au taf : j'ai géré deux Redmine dans des machines virtuelles sur un serveur OVH pour notre petite équipe.
chez moi : pour mes (tout) petits projets perso, ou pour dépanner quand j'ai filé un coup de main à un pote pour une création de boîte, pareil, machine virtuelle.
Pour toutes ces VM, la Debian du moment, parfois en testing, pour avoir une version un peu plus récente de Redmine.
De base, c'est quasiment aussi simple qu'un apt(-get) install redmine.
Mais ça tire beaucoup de dépendances, dont Ruby on Rails, que je ne maîtrise absolument pas.
Autre problème, surtout si la VM est en Debian testing, une mise à jour, et surtout, un saut de version Debian (ex: 12 - Bookworm vers 13 - Trixie) a tendance à tout casser. C'est pour ça que je déconseille si Redmine doit rester à jour tout le temps.
Git & cie; remarque repo
Redmine gère à peu près tous les gestionnaires de code/version. Le site dit : "SVN, CVS, Git, Mercurial and Bazaar".
Petite remarque concernant git. Je ne sais pas si la proportion d'utilisateur de git connaissant ceci est grande ou petite. Donc je case ça ici "okazou" : pas besoin de GitHub (ou autre) pour avoir un repo centralisé sur un serveur.
Par centralisé, je veux dire : commun à une équipe par exemple, que ce soit en entreprise, ou au quatre coins de la planète.
Un répertoire, un coup de git init --bare, c'est terminé.
Il est possible d'accéder à ce répertoire via ssh, avec une URL du genre ssh://<user>@<serveur>:<port>/path/to/the/repo (git clone ..., git remote ..., etc).
De par ma faible expérience de GitHub, je dirais que :
GitHub crée automatiquement des "pull requests" quand quelqu'un pousse du code (propos à nuancer par des utilisateurs intensifs).
repo "manuel" : en cas de grosse équipe (à partir de 2 !), la rigueur s'impose, essentiellement dans la gestion des branches et de l'intégration, afin que les gens ne se marchent pas sur les pieds.
Mais un repo créé "a la mano" fera aussi bien le boulot.
Il n'y a pas vraiment de problème.
Mais les fonctionnalités sont basiques, comparées aux autres outils cités ici.
PuTTY ne propose pas d'auto-reconnexion par exemple. Mais rendons à PuTTY … C'est d'abord un outil de connexion SSH et Telnet.
Merci pour l'info, c'est bon à savoir, et c'est l'occasion de changer mes mauvaises habitudes. La preuve : j'utilise encore PuTTY pour de la liaison série ! À ma décharge, je suis parfois obligé de travailler sous Windows plutôt que Linux, et PuTTY reste le même. Par contre, quelle blague, ces ports COMx sous Windows …
Je mentionne CuteCom juste pour le principe, et parce qu'il a aussi une case à cocher "Auto reconnect". Et parce que c'est une IHM, pour ceux qui préfèrent.
IHM dont je me passerai avec joie en testant tio !
Au passage, j'utilise quelques adaptateurs USB-UART basés sur des puces FTDI. À ma connaissance, ce sont les seules à présenter un numéro de série.
J'utilise ce numéro de série pour créer un lien symbolique dans /dev, via une règle udev, et éviter ainsi le caractère aléatoire de l'énumération des périphériques sur les bus USB.
C'est à dire qu'une puce FTDI peut être détectée comme /dev/ttyUSB2, et une autre fois comme /dev/ttyUSB0. Avec une règle udev1 , un lien symbolique, par exemple /dev/ttyFTDI5 -> ttyUSB0 est créé à chaque démarrage. Et je peux m'adresser à /dev/ttyFTDI5 sans me préoccuper de l'ordre de détection (et grace à une petite étiquette "5" collée sur la puce en question).
Avec d'autres puces, comme les CHxxx, il me semble que c'est impossible. Avec udevadm, je n'ai jamais trouvé de propriété exploitable pour arriver au même résultat.
1 : KERNEL=="ttyUSB*", ATTRS{serial}=="<n° de série de votre puce FTDI>", SYMLINK+="ttyFTDI5" placé dans un fichier /etc/udev/rules.d/<nom de votre choix>.rules
Mauvaise nouvelle : ça fait très longtemps que j'utilise cette extension. Très pratique, en particulier pour ceux, comme moi, qui écrivent moult fautes et erreurs d'inattention. Et à force de lire, écrire et écouter pas mal d'anglais, sans être véritablement "fluent", il y a un paquet de mots dont l'orthographe est mélangée (exemple : connection …).
J'ai l'air c*n : dans ma liste de plugins, cet outil est dénommé "AI Grammar Checker & Paraphraser – LanguageTool". Et la plupart du temps, quand je vois "AI" ou "IA", je m'éloigne en courant …
Je vais essayer de suivre ce journal pour savoir si le risque détecté est bien avéré.
Ah mais dans le message initial, il n'est pas fait mention du Cloud.
Vu les restrictions réseau, j'en ai conclu qu'il fallait juste récupérer les données de l'appareil en local, sans lien avec quoi que ce soit.
J'ai commencé par installer une machine virtuelle Windows 10.
Avec du réseau pour faire les mises à jour.
Mais dans votre cas, ça n'est peut-être même pas nécessaire.
J'ai ensuite installé les extensions ("Guest Additions" ici où je mets tout en anglais).
Une fois prête à l'usage, j'ai désactivé l'interface réseau dans les paramètres de la machine virtuelle.
Et j'ai ajouté un répertoire partagé, en utilisant la fonctionnalité de VirtualBox, pas en passant par un partage réseau (forcément).
Et ça fonctionne : du point de vue de la machine virtuelle, plus de réseau, l'interface est désactivée. Mais je peux accéder au contenu du répertoire partagé.
De cette manière, je pense que votre objectif est atteint : un Windows fonctionnel, pas besoin de règle de firewalling puisque pas de réseau du tout, mais échange possible de données par copie dans le répertoire partagé.
[^] # Re: Expérience Redmine (limitée)
Posté par pseudonymous . En réponse au message Choix d’un outil pour gérer des projets sur Linux. Évalué à 3 (+2/-0).
Yep, sympa à utiliser.
Très "customizable", en particulier la gestion des tickets ("issues"), pour l'adapter à la méthode de gestion des bugs (par exemple, ajout de champs "Contexte", "problème constaté", "résultat attendu", etc). + possibilité de hiérarchiser les tickets.
Au passage, lien faciles dans tous les sens, entre les tickets, le Wiki intégré et les commit dans les repo lié au projet.
Avec par exemple, des liens ticket --> commit, mais aussi commentaire de commit --> ticket(s) concerné(s).
Fun fact (comme disent les djeunz !) : pas au top quand il s'agit d'extraire une liste de tickets, avec les commentaires et images jointes. Du coup, je m'étais fait un utilitaire qui parcourait la database Redmine, permettait de filtrer et de générer une page Web. Ensuite, c'était facile à transformer en PDF, pour l'envoyer à un fournisseur par exemple, si on ne veut pas lui donner un compte Redmine.
Faudra que j'essaye de passer par le tgz, parce que là, après quelques mois d'inutilisation, je constate que mon Redmine perso est cassé, et les logs ne sont pas mes amis pour comprendre d'où ça vient …
# Expérience Redmine (limitée)
Posté par pseudonymous . En réponse au message Choix d’un outil pour gérer des projets sur Linux. Évalué à 5 (+4/-0).
Avant Redmine
La première fois que je l'ai utilisé, c'était après une petite étude des outils du domaine. Je me rappelle vaguement Trac, pas les autres.
Malgré les bémols qui suivent, j'ai choisi Redmine parce que plus simple à installer et auto-héberger (chez OVH ou à la maison).
Redmine
Petit retour d'expérience sur Redmine, par un type qui est carrément plus codeur qu'adminsys, mais qui s'est retrouvé à gérer de tels outils, au taf ou pour lui-même.
TL;DR : je déconseille s'il faut le garder à jour en permanence. Sauf à être nettement plus versé que moi dans l'admin.
au taf : j'ai géré deux Redmine dans des machines virtuelles sur un serveur OVH pour notre petite équipe.
chez moi : pour mes (tout) petits projets perso, ou pour dépanner quand j'ai filé un coup de main à un pote pour une création de boîte, pareil, machine virtuelle.
Pour toutes ces VM, la Debian du moment, parfois en
testing, pour avoir une version un peu plus récente de Redmine.De base, c'est quasiment aussi simple qu'un
apt(-get) install redmine.Mais ça tire beaucoup de dépendances, dont
Ruby on Rails, que je ne maîtrise absolument pas.Autre problème, surtout si la VM est en Debian
testing, une mise à jour, et surtout, un saut de version Debian (ex: 12 - Bookworm vers 13 - Trixie) a tendance à tout casser. C'est pour ça que je déconseille si Redmine doit rester à jour tout le temps.Git & cie; remarque repo
Redmine gère à peu près tous les gestionnaires de code/version. Le site dit : "SVN, CVS, Git, Mercurial and Bazaar".
Petite remarque concernant git. Je ne sais pas si la proportion d'utilisateur de git connaissant ceci est grande ou petite. Donc je case ça ici "okazou" : pas besoin de GitHub (ou autre) pour avoir un repo centralisé sur un serveur.
Par centralisé, je veux dire : commun à une équipe par exemple, que ce soit en entreprise, ou au quatre coins de la planète.
Un répertoire, un coup de
git init --bare, c'est terminé.Il est possible d'accéder à ce répertoire via ssh, avec une URL du genre
ssh://<user>@<serveur>:<port>/path/to/the/repo(git clone ...,git remote ..., etc).De par ma faible expérience de GitHub, je dirais que :
GitHub crée automatiquement des "pull requests" quand quelqu'un pousse du code (propos à nuancer par des utilisateurs intensifs).
repo "manuel" : en cas de grosse équipe (à partir de 2 !), la rigueur s'impose, essentiellement dans la gestion des branches et de l'intégration, afin que les gens ne se marchent pas sur les pieds.
Mais un repo créé "a la mano" fera aussi bien le boulot.
[^] # Re: CuteCom
Posté par pseudonymous . En réponse au lien Oubliez Minicom et screen: "tio - a serial device I/O tool" . Évalué à 1 (+1/-0).
Il n'y a pas vraiment de problème.
Mais les fonctionnalités sont basiques, comparées aux autres outils cités ici.
PuTTY ne propose pas d'auto-reconnexion par exemple. Mais rendons à PuTTY … C'est d'abord un outil de connexion SSH et Telnet.
# CuteCom
Posté par pseudonymous . En réponse au lien Oubliez Minicom et screen: "tio - a serial device I/O tool" . Évalué à 5 (+5/-0).
Merci pour l'info, c'est bon à savoir, et c'est l'occasion de changer mes mauvaises habitudes. La preuve : j'utilise encore
PuTTYpour de la liaison série ! À ma décharge, je suis parfois obligé de travailler sous Windows plutôt que Linux, et PuTTY reste le même. Par contre, quelle blague, ces ports COMx sous Windows …Je mentionne
CuteComjuste pour le principe, et parce qu'il a aussi une case à cocher "Auto reconnect". Et parce que c'est une IHM, pour ceux qui préfèrent.IHM dont je me passerai avec joie en testant
tio!Au passage, j'utilise quelques adaptateurs USB-UART basés sur des puces FTDI. À ma connaissance, ce sont les seules à présenter un numéro de série.
J'utilise ce numéro de série pour créer un lien symbolique dans
/dev, via une règleudev, et éviter ainsi le caractère aléatoire de l'énumération des périphériques sur les bus USB.C'est à dire qu'une puce FTDI peut être détectée comme
/dev/ttyUSB2, et une autre fois comme/dev/ttyUSB0. Avec une règleudev1 , un lien symbolique, par exemple/dev/ttyFTDI5 -> ttyUSB0est créé à chaque démarrage. Et je peux m'adresser à/dev/ttyFTDI5sans me préoccuper de l'ordre de détection (et grace à une petite étiquette "5" collée sur la puce en question).Avec d'autres puces, comme les CHxxx, il me semble que c'est impossible. Avec
udevadm, je n'ai jamais trouvé de propriété exploitable pour arriver au même résultat.1 :
KERNEL=="ttyUSB*", ATTRS{serial}=="<n° de série de votre puce FTDI>", SYMLINK+="ttyFTDI5"placé dans un fichier/etc/udev/rules.d/<nom de votre choix>.rules[^] # Re: A noter que le serveur distant peut être auto-hébergé
Posté par pseudonymous . En réponse au journal J'ai failli le faire. Évalué à 4 (+4/-0).
Bon à savoir.
Et c'est ici qu'il faut creuser la question apparemment.
# Mauvaise nouvelle et j'ai l'air c*n
Posté par pseudonymous . En réponse au journal J'ai failli le faire. Évalué à 4 (+4/-0).
Merci pour la vigilance.
Mauvaise nouvelle : ça fait très longtemps que j'utilise cette extension. Très pratique, en particulier pour ceux, comme moi, qui écrivent moult fautes et erreurs d'inattention. Et à force de lire, écrire et écouter pas mal d'anglais, sans être véritablement "fluent", il y a un paquet de mots dont l'orthographe est mélangée (exemple : connection …).
J'ai l'air c*n : dans ma liste de plugins, cet outil est dénommé "AI Grammar Checker & Paraphraser – LanguageTool". Et la plupart du temps, quand je vois "AI" ou "IA", je m'éloigne en courant …
Je vais essayer de suivre ce journal pour savoir si le risque détecté est bien avéré.
# Ensuite ?
Posté par pseudonymous . En réponse au journal Tour des GULL : étape 14 - Journées nationales de la réparation à Lille. Évalué à 3 (+4/-1).
C'était bien sympa apparemment !
D'autres journées du genre sont-elles prévues ? Existe-t-il un site, un calendrier ?
[^] # Re: Solution VirtualBox et sans réseau
Posté par pseudonymous . En réponse au message Créer une machine virtuelle windows 10 avec un accès très restreint au réseau. Évalué à 2 (+1/-0).
Ah mais dans le message initial, il n'est pas fait mention du Cloud.
Vu les restrictions réseau, j'en ai conclu qu'il fallait juste récupérer les données de l'appareil en local, sans lien avec quoi que ce soit.
# Solution VirtualBox et sans réseau
Posté par pseudonymous . En réponse au message Créer une machine virtuelle windows 10 avec un accès très restreint au réseau. Évalué à 3 (+2/-0).
Hello,
Je viens de faire l'expérience avec VirtualBox.
J'ai commencé par installer une machine virtuelle Windows 10.
Avec du réseau pour faire les mises à jour.
Mais dans votre cas, ça n'est peut-être même pas nécessaire.
J'ai ensuite installé les extensions ("Guest Additions" ici où je mets tout en anglais).
Une fois prête à l'usage, j'ai désactivé l'interface réseau dans les paramètres de la machine virtuelle.
Et j'ai ajouté un répertoire partagé, en utilisant la fonctionnalité de VirtualBox, pas en passant par un partage réseau (forcément).
Et ça fonctionne : du point de vue de la machine virtuelle, plus de réseau, l'interface est désactivée. Mais je peux accéder au contenu du répertoire partagé.
De cette manière, je pense que votre objectif est atteint : un Windows fonctionnel, pas besoin de règle de firewalling puisque pas de réseau du tout, mais échange possible de données par copie dans le répertoire partagé.
Hope this helps.