Alouette-II (JSBSim twin engine)

HH64 · 8/12/2021 11:11:13

Bonjour Clm76, Dany93,

@Dany93

J'ai eu une mauvaise surprise, une incertitude qui m'a inquiété et dont j'ai eu du mal à trouver la cause.
Les fps étaient bas (10 - 25 fps) avec, surtout, des figeages (2 - 3 par sec). Impraticable.
De plus, j'avais une liste de propriétés affichées qui ne m'intéressaient pas et qui se superposaient à la liste équivalente que je me suis faite. Je n'ai par ailleurs jamais remarqué que la mienne ralentissait (un fichier nasal externe à FG, 10 à 20 propriétés).

En cours de développement, certaines aides sont utiles mais concernent moins l'utilisateur courant. L'appel à ces aides est paramétrable dans Alouette-II-jte-set.xml dans la section _debug.
En paramétrant un frame rate cohérent (20 fps), ces aides ne pénalisent pas vraiment le modèle sur ma machine. Pour autant, avec un framerate "libre", il apparaît qu'elles sont consommatrices de puissance CPU. En d'autres termes, ces aides impactent plus ou moins le modèle en fonction de la machine utilisateur et il importe qu'elles soient cachées par défaut.

C'est corrigé sur Mediafire et Git.

(Réponses sur les autres points au fil de l'eau dans différents messages.)

HH64 · 8/12/2021 11:17:58

àDany93,

Quel fonctionnement allons-nous adopter pour proposer et éventuellement inclure nos modifications dans "Master" ?
@HH64, tu es le créateur et l'acteur principal de ce projet, je ne vois pas la nécessité de nous demander notre accord avant de pusher une modif (sauf incertitude de ta part). Ce serait d'autant plus gênant que tu en ajoutes souvent et beaucoup.
En ce qui me concerne, ma préférence irait vers une création de branche de test qui vous permettrait d'essayer, puis d'approuver ou non. Le contenu de cette branche de test étant sans effet sur celle "master", il n'y a pas d'effet négatif.
Ensuite si approuvé., un de nous (ou moi, pour commencer) cliquerait sur le bouton "Merge" dans la branche "master".
Je vous guiderai pour les commandes à entrer pour obtenir le contenu d'une branche, observer les fichiers, la tester et la supprimer à la fin. Pas de roulage des mécaniques, je ne connais pas ça sur le bout des doigts mais avec mes notes je pense que cela devrait aller sans trop d'aléas.
Le passage d'une branche à l'autre pour modifs ou tests est très facile.
J'ai une proposition sous le coude (message à suivre) qui pourrait servir de galop d'essai.

Totalement inexpérimenté en matière de développement informatique, de surcroît collaboratif, je suis entièrement à ton écoute. De plus, je n'ai aucune réticence à vous accorder les mêmes droits que moi, voire à céder le temps de l'apprentissage le "leadership" si nécessaire. Pour information, j'utilise TeamViewer et Mumble.

Dernière modification par HH64 (8/12/2021 11:20:29)

HH64 · 8/12/2021 11:43:54

@Dany93,

Je suppose que l'indicateur de vitesse est, comme pour les avions, basé sur une seule sonde de pitot orientée suivant l'axe de l'hélicoptère (X pour nous)

Je propose donc de remplacer"instrumentation/airspeed-indicator/indicated-speed-kt" par "fdm/jsbsim/velocities/u-aero-fps".

C'est un point notable pour lequel FG (générique) et ses HUDs ne me conviennent pas, en effet beaucoup trop imprécis à basses vitesses, cas du vol stationnaire.

Je suis en accord avec toi et contrairement à un avion dans son domaine de vol, un hélicoptère peut adopter des vitesses négatives (marche arrière) et je privilégie "/velocities/uBody-fps" (sous les formes /velocities/smooth-kt ou /velocities/smooth-kt-filtered dans instruments.xml). C'est imparfait mais utile pour apprécier la marche arrière et maîtriser le mode auto-stationnaire.

Si Clm76 approuve, je/tu procéderai/as aux modifications que tu suggères.

Si cela vous convient, je propose de créer un sujet dans GitHub et une branche de test pour cette démarche.

Ca me convient, un petit pas pour commencer et se laisser conduire...

Question subsidiaire: un seul pitot permet-il de mesurer les "vitesses négatives" ? Faut-il adopter un badin qui couvre les vitesses 0, -40kt ?

Dernière modification par HH64 (8/12/2021 12:07:37)

HH64 · 8/12/2021 12:05:32

@Dany93, @Clm76,

Je le copiais ou clonais sur ma machine. Je n'ai pas l'habitude de travailler directement dans GitHub, trop peur de faire des bêtises !!!

Nous sommes au moins deux .

J'ai sur mon PC une copie locale et synchronisée du dépôt GitHub C:\GitHub\Alouette-II-jte. Pour autant, ce n'est pas mon original B:\FlightGear\data\Aircraft\Alouette-II-jte, lequel est à nouveau copié dans D:\where_to_compress\Alouette-II-jte réservé à Mediafire. Cela commence à faire beaucoup

dany93 · 8/12/2021 12:20:14

Bonjour HH64,

HH64 a écrit :

Sans explication qui me satisfasse, je ne recevais plus les mails m'informant de nouveaux messages sur cette discussion... D'où mon silence.

Un bug...

As-tu vérifié ""Vous suivez cette discussion" ? Éventuellement désactiver puis réactiver ?

Ou dans "Vie privée : "Suivre automatiquement les sujets auxquels on a répondu" ?

Bloqués en Indésirables / SPAMS par un fournisseur Internet qui ne sait pas gérer ?

HH64 · 8/12/2021 12:26:12

@Dany93, @Clm76,

Pour votre information,

J'ai travaillé sur une Alouette-II-jsbsim "mono-turbine" et pense pouvoir confirmer les craintes de Martin Litzenberger (metteur au point de l'Alouette-III bi-turbine...).

To distribute the power demand between the two engines I use a table with an S-curve like function, with input from the dummy rotors (shaft) RPM difference, in engineX-control.xml. Thus, in case of RPM difference between the engines, only the faster engine "drives" the rotor.
The challenge however that remains with this approach is to design a "neutral" dummy rotor (for simulating the shaft) with minimum negative side effect on the overall models flight characteristics (minimal thrust,..).

En clair, les "dummy-rotors" impactent significativement le comportement de l'aéronef. In fine, Jsbsim permet-il de traiter le cas de l'hélicoptère bi-turbine (:/) en restant neutre d'un point de vue comportement aérodynamique ?

En mono-turbine, le rotor de queue reste entraîné par un "dummy-rotor", sans influence semble-t-il sur son comportement.

Je vous proposerai après des essais plus aboutis de passer à cette version plus compatible à une diffusion hors développement (version disponible dès à présent si vous le souhaitez).

HH64 · 8/12/2021 12:38:20

@Dany93,

As-tu vérifié ""Vous suivez cette discussion" ? Éventuellement désactiver puis réactiver ?

"Désactiver puis réactiver" a répondu à mon soucis de suivi... Aucune trace des messages dans ma boîte email, spams compris!
Merci.

dany93 · 8/12/2021 12:40:08

HH64 a écrit :

un seul pitot permet-il de mesurer les "vitesses négatives" ? Faut-il adopter un badin qui couvre les vitesses 0, -40kt ?

Il est presque certain que non. Une vitesse négative ne crée pas une dépression mesurable au Pitot.

Encore faudrait-il que le badin comporte des graduations en vitesses négatives. Jamais vu (probablement because ligne précédente).
De toutes façons, dans la réalité, je ne pense pas que ce soit le cas. Si mesure de vitesses négatives il y a, je pense que c'est par GPS ou mesure locale différentielle (repères fixes locaux proches). Plutôt pour assister en stationnaire.

@Clm76 ? (encore sollicité !! )

dany93 · 8/12/2021 13:14:33

Clm76 a écrit :

Je le copiais ou clonais sur ma machine. Je n'ai pas l'habitude de travailler directement dans GitHub, trop peur de faire des bêtises !!!

HH64 a écrit :

J'ai sur mon PC une copie locale et synchronisée du dépôt GitHub

Rassurez-vous, il y en a d'autres !

Cependant, une branche (de test, pour permettre aux autres contributeurs d'essayer, ou destinée à proposer plus tard un "merge request") est sans danger pour la branche principale (pour master).
A sa création, elle est semblable à "master". Puis on modifie, on fait "Add", on fait "commit" (ou non)... Par contre avec "Add" et "commit", l'historique local contient alors tous les essais, ce qui n'est pas souhaitable à pusher. D'où l'intérêt de faire les essais dans un copie locale hors git. Ou sur une branche qu'on ne pushera pas. Puis de n'intégrer que le code à pusher.

Travailler sur une branche locale est sans danger car, tant qu'elle n'est pas pushée, elle est supprimable sans pollution du dépôt distant, sans que personne ne s'en rende compte. Quitte à sauvegarder son contenu ailleurs, pour trier ensuite, avant de la supprimer quand on en vient à ce genre de remise en ordre.
Et même si elle a été pushée sur le dépôt distant en tant que branche, mais non fusionnée (pas de "Merge" dans master), elle peut être supprimée aussi sur le dépôt distant. Puis recréée pour travailler proprement.

Au pire si tout va mal,

git reset --hard HEAD~

ou

git reset --hard origin/master

ou

git reset --hard origin/<branch>

Vous remet tout localement dans l'état de votre dernier "git pull". Mais vous perdez toutes vos modifications si vous ne les avez pas sauvegardées avant en un autre endroit.

dany93 · 8/12/2021 13:39:03

HH64 a écrit :

Si Clm76 approuve, je/tu procéderai/as aux modifications que tu suggères.

(pour rappel, on parle de la source de mesure de vitesse badin)

Ne te presse pas trop.
- Si Clm76 trouve que c'est hors d'intérêt, que le comportement du badin FG (vitesses toujours 30 ... 40 km/h) se retrouve dans la réalité, on arrête là ou on met ça au frigo.
- Sinon, je crée une branche et on en profite pour faire la démarche "branche", tests par vous... en vraie grandeur.
Ensuite, on "merge" ou non.

De plus, comme c'est une modification très localisée et sans impact secondaire, on pourrait facilement rétablir l'ancienne mesure par un autre commit dans master.

Clm76 · 8/12/2021 18:07:24

dany93 a écrit :

- Si Clm76 trouve que c'est hors d'intérêt, que le comportement du badin FG (vitesses toujours 30 ... 40 km/h) se retrouve dans la réalité, on arrête là ou on met ça au frigo.
- Sinon, je crée une branche et on en profite pour faire la démarche "branche", tests par vous... en vraie grandeur.
Ensuite, on "merge" ou non.
De plus, comme c'est une modification très localisée et sans impact secondaire, on pourrait facilement rétablir l'ancienne mesure par un autre commit dans master.

Dans la réalité, quand on amorce un stationnaire ou un atterrissage, on se préoccupe moins du badin, dont on sait qu'il est faux aux basses vitesses, que des vues horizontales et verticales pour savoir si on avance, recule, descend etc...
Ceci dit, on peut effectivement créer une branche test et voir ce que ça donne.

Clm76 · 9/12/2021 12:58:08

Bonjour,

Je viens d'effectuer un "commit" et un "push" sur l'A2 pour corriger des erreurs de majuscules et minuscules sur des "lights" (greenlights au lieu de GreenLights, redlights au lieu de RedLights et whitelights au lieu de WhiteLights).

J'attire quand même votre attention sur le fait que mon "push" a directement modifié le "master", ce qui veut dire que j'ai les droits d'écriture directe. Il serait peut-être bon que quelqu'un (HH64 comme chef de projet ou dany93) ait la supervision de ce projet et autorise ou non les modifications.

HH64 · 9/12/2021 13:58:21

Bonjour,

@Clm76

J'ai bien noté tes modifications sur Github, lesquelles entraînent quelques questions.

Les fichiers GreenLight.xml, RedLight.xml, WhiteLight.xml ont été rebaptisés greenlight.xml, redlight.xml, whitelight.xm. Est-ce par convention? Est-ce la raison qui a conduit à modifier le code ?

En ce cas, faut-il que les .ac soient en minuscules? Le dossier lights doit-il devenir Lights ?

(convention: nom de fichiers en minuscules, nom de dossier commence par une majuscule.)

@Dany93

Où se fait le rapatriement sur son dépôt local, pull origin sur GitHub Desktop ?
Je suis tes consignes pour la tenue du dépôt, trop peur d'effacer vos apports (en espérant que ça n'est pas déjà le cas!).

dany93 · 9/12/2021 16:21:35

HH64 a écrit :

Où se fait le rapatriement sur son dépôt local, pull origin sur GitHub Desktop ?

Je ne connais pas GitHub Desktop. (Windows ?)
Je crois comprendre qu'il fait la même chose que

git pull origin master

git pull origin nom-de-branche

pour fusionner "master" ou "nom-de-branche" dans ta branche locale active.
Mais en interface graphique plus conviviale.

trop peur d'effacer vos apports

Tu as peu de chances d'effacer nos contributions sans le vouloir par la gestion git.
En supposant que nous ayons fait plusieurs commits, pour inverser un commit, il faudrait faire un "git revert <...>".
Sinon, tu peux évidemment supprimer ce qu'on a écrit en remplaçant nos lignes dans un fichier, mais tu ne le ferais pas inconsciemment.
Et personne n'est à l'abri d’erreurs. Alors on se débrouillera pour réparer avec le contenu de nos anciens fichiers ou en consultant l'historique de git (commits précédents).

Clm76 a écrit :

J'attire quand même votre attention sur le fait que mon "push" a directement modifié le "master", ce qui veut dire que j'ai les droits d'écriture directe. Il serait peut-être bon que quelqu'un (HH64 comme chef de projet ou dany93) ait la supervision de ce projet et autorise ou non les modifications

Je n'ai jamais eu à faire cette gestion, je ne sais pas où elle se configure. HH64 (créateur du dépôt) est peut-être le seul à avoir ce droit.
Mais une fois que nous en sommes conscients, cela ne devrait pas être un problème.

Dans la mesure où il n'y a qu'une branche (master) actuellement, il n'y a pas d'incertitude : pull et push sont depuis et vers master.

On peut savoir où on va pusher (et d'où on va "puller")
Exemple sur le c172p (car nous n'avons que master sur Alouette-II-jte)

On vérifie sur quelle branche on est :

 ~/FG/github/c172p $ git status
Sur la branche Issue-1378

~/FG/github/c172p $ git remote show origin
* distante origin
  URL de rapatriement : git@github.com:c172p-team/c172p.git
  URL push : git@github.com:c172p-team/c172p.git
  Branche HEAD : master
  Branches distantes :
   Issue-1308                         suivi
    Issue-1378                         suivi
    startup-and-saved-state-system     suivi
  Branches locales configurées pour 'git pull' :
    Issue-1378       fusionne avec la distante Issue-1378
    master           fusionne avec la distante master
  Références locales configurées pour 'git push' :
    Issue-1378 pousse vers Issue-1378 (à jour)
    master     pousse vers master     (à jour)

On a la liste des branches distantes, importées ou non, et à la fin celles avec lesquelles on fusionne (pull) ou vers lesquelles on pousse (push).

Pour éviter les erreurs, bien vérifier (git status) sur quelle branche on est avant de faire un simple "git pull" ou "git push",

A prendre quand même avec précautions car je ne connais pas tout ça sur le bout des doigts

dany93 · 9/12/2021 19:18:30

J'ai créé une branche Issue-1 : " Indication de vitesse, source u-aero-fps au lieu de indicated-speed-kt".

Le nom est au choix, il peut être plus explicite. Ici, numéro de l'issue donné par GitHub pour faciliter la liaison pendant la durée de vie de la branche.
La branche est normalement (sur proposition) supprimée lors du "merge". Le nom disparaît en même temps.

Pour tester :

Importer nouveaux commits et branches :

git fetch origin

Puis pour les voir :

git remote show origin

(vous voyez la liste des branches)

Se connecter sur la branche :

git checkout Issue-1

Cette branche est importée, créée dans votre dépôt local.
Votre répertoire de travail est mis à jour avec le contenu de cette branche.
Vous pouvez ouvrir et observer les fichiers, dont celui modifié,
Le contenu de votre dépôt local étant celui d'Issue-1, vous pouvez en tester l'effet dans le simulateur.

Pour revenir à master :

git checkout master

Et inversement.

Dernière modification par dany93 (9/12/2021 19:24:11)

Clm76 · 9/12/2021 19:29:17

HH64 a écrit :

J'ai bien noté tes modifications sur Github, lesquelles entraînent quelques questions.
Les fichiers GreenLight.xml, RedLight.xml, WhiteLight.xml ont été rebaptisés greenlight.xml, redlight.xml, whitelight.xm. Est-ce par convention? Est-ce la raison qui a conduit à modifier le code ?
En ce cas, faut-il que les .ac soient en minuscules? Le dossier lights doit-il devenir Lights ?
(convention: nom de fichiers en minuscules, nom de dossier commence par une majuscule.)

J'ai rebaptisé les fichiers en question car ils produisaient des erreurs en console. A l'origine, les fichiers "GreenLight.xml", "RedLight.xml" et "WhiteLight.xml" (dans Models/lights") comportaient des majuscules. Quelqu'un (toi ??) a remplacé les majuscules par des minuscules. De ce fait, Fg ne trouvait plus les fichiers correspondant dans "alouette2.xml" et "r22.xml"

  <model>
    <path>/Aircraft/Alouette-II-jte/Models/lights/RedLight.xml</path>
    <offsets>
      <x-m>-2.25</x-m>
      <y-m>-0.7947</y-m>
      <z-m>-1.16</z-m>
    </offsets>
  </model>

  <model>
    <path>/Aircraft/Alouette-II-jte/Models/lights/GreenLight.xml</path>
    <offsets>
      <x-m>-2.25</x-m>
      <y-m>0.7947</y-m>
      <z-m>-1.16</z-m>
    </offsets>
  </model>

  <model>
    <path>/Aircraft/Alouette-II-jte/Models/lights/WhiteLight.xml</path>
    <offsets>
      <x-m>6.22</x-m>
      <y-m>0.0012</y-m>
      <z-m>-0.1146</z-m>
    </offsets>
  </model>

HH64 a écrit :

En ce cas, faut-il que les .ac soient en minuscules? Le dossier lights doit-il devenir Lights ?
(convention: nom de fichiers en minuscules, nom de dossier commence par une majuscule.)

Ce serait mieux en effet. Les dossiers avec la première lettre en majuscule et les fichiers tout en minuscule.

dany93 a écrit :

J'ai créé une branche Issue-1 : " Indication de vitesse, source u-aero-fps au lieu de indicated-speed-kt".

Ok. La branche fonctionne nickel

Dernière modification par Clm76 (9/12/2021 19:42:49)

dany93 · 10/12/2021 12:17:39

Bonjour HH64, bonjour Clm76,

@Clm76, merci du retour.

J'ai ajouté quelques "Labels" dans GitHub pour faciliter nos identifications d'actions, classements et recherches d'Issues. Par exemple, ce dernier sujet : label "animations (XML)".
Labels modifiables et supprimables facilement si cela ne vous va pas. Managing labels.

dany93 · 10/12/2021 16:51:36

Bonjour HH64, bonjour Clm76,

La branche "Issue-1" étant fusionnée (merci HH64), il vous faut nettoyer votre dépôt local.
GitHub a fermé le sujet "Issue-1" en fusionnant la branche dans master, et il me proposait de supprimer la branche "Issue-1". Ce que j'ai fait (dépôt distant).

En faisant git branch, vous trouvez

git branch
* Issue-1
  master

Pour supprimer Issue-1 :

git checkout master

(si ce n'est pas déjà fait)

puis (possiblement superflu, pour assurer la mise à jour de la liste locale)

git fetch origin

Enfin, suppression de la branche locale proprement dite :

git branch -d Issue-1

Ensuite,

git remote show origin

Montre que Issue-1 (dépassée) est toujours dans votre liste locale.
Faire

git remote prune origin

ou

git fetch origin --prune

pour la supprimer de la liste.

dany93 · 10/12/2021 17:17:57

Souhaitez-vous prolonger l'expérimentation de cette procédure ?
C'est plus une question pour @Clm76, création de branches.
@HH64 peut en général "pousser" lui-même dans master, mais cela peut-être utile pour proposer une modification pas évidente.

Si oui, il faut que je rédige la suite des instructions pour créer votre branche locale, la pousser sur le dépôt GitHub, aller jusqu’au Pull Request.

Clm76 · 10/12/2021 18:20:27

dany93 a écrit :

Souhaitez-vous prolonger l'expérimentation de cette procédure ?
C'est plus une question pour @Clm76, création de branches.

Qu'entends-tu par là ?
Sur mon ordi, j'ai maintenant la branche issue-1. J'ai fait un "git pull -r" ce matin et ça m'a renvoyé que ma branche était à jour. Donc, pour moi, ça fonctionne comme avec le Citation X dans SVN.
Ceci dit, je suis prêt à toutes les expérimentations possibles...

[EDIT] Désolé, je n'avais pas vu ton précédent post concernant la fusion de la branche "Issue-1" avec "master".
C'est fait, la suppression de la branche locale "Issue-1" s'est bien déroulée et je suis maintenant à nouveau sur "master". Un "git pull" m'a ramené les modifications effectuées sur master avec la fusion.

Dernière modification par Clm76 (10/12/2021 18:36:18)

HH64 · 10/12/2021 19:14:06

Bonsoir à tous,

@Dany93

Je suis en déplacement. Github à jour, je crois. Bon weekend et surtout moins d'eau que dans le 64.

dany93 · 10/12/2021 19:53:21

Ensuite, si vous voulez proposer un nouveau code par l'intermédiaire d'une branche en vue de fusion après acceptation :

En local :

(si ce n'est déjà fait)

git checkout master

Assurer la mise à jour :

git pull

Créer la branche locale et s'y connecter :

git checkout -b mynew-branch

Effectuer les modifications.

Puis (comme d'hab')

git add -A
git commit -m "mon message"

Pousser la branche :

git push -u origin mynew-branch

Crée "mynew-branch" distante et pousse le contenu de votre dépôt local (HEAD, mynew-branch) vers origin mynew-branch.
Et (-u) déclare "mynew-branch" distante comme suivie par votre dépôt local. "git pull" et "git push" se feront depuis et vers cette branche distante.

A ce stade, vous pouvez vérifier sur GitHub que votre branche a bien été créée (en plus de master, menu déroulant).

Dans GitHub :

Dans le menu déroulant des branches, sélectionner "my-new-branch".
(si rien n'est encore fait, il y a des boutons "Compare and pull request" et "Pull request")

Ouvrir un "Issue" descriptif d'un problème.
(facultatif, on peut ouvrir directement un Pull request, avec description)
La branche peut répondre à un problème déjà posé. L'Issue existe alors avant l'apparition de la branche.

Ouvrir un "Pull request" (vérifier son association à la bonne branche).
Si un "Issue" associé existe, mettre en tête de message :

Fixes #N

où N est le numéro de l'Issue.
Ainsi, l'Issue #N sera automatiquement fermé lors de la fusion de la branche.
A la fusion, GitHub proposera alors de supprimer la branche de son dépôt.

Dernière modification par dany93 (29/12/2021 21:12:49)

Clm76 · 11/12/2021 11:34:27

Bonjour,

J'ai créé et pushé une nouvelle branche appelée "clm-11" (11 pour la date du jour) avec les modifications suivantes :

- Suppression des appels à Renbrandt sur les instruments VSI, VOR et Gyro car les versions 2020.4 de FG ne supportent plus Rembrandt.
- Suppression des "BackLight" sur les ".ac" de ces mêmes instruments car ils étaient opaques sur les dernières versions de Fg.

Dans Github, j'ai effectué ensuite un "pull request" suivi d'un "merge" qui a modifié le master et fermé ma branche "clm-11".

clm76 merged commit bde4a37 into master 2 minutes ago

Pull request successfully merged and closed

You’re all set—the clm-11 branch can be safely deleted.

Je n'ai pas encore supprimé la branche.

@ HH64, dany93 :
Je me pose toutefois la question de savoir si c'est normal que je puisse "merger" sans l'accord de HH64. C'est son "bébé" après tout !...
Ce serait plutôt à lui d'effectuer cette fusion, non ? Qu'en pensez-vous ?

Dernière modification par Clm76 (11/12/2021 11:49:14)

dany93 · 11/12/2021 12:53:53

lm76 a écrit :

Je me pose toutefois la question de savoir si c'est normal que je puisse "merger" sans l'accord de HH64. C'est son "bébé" après tout !... wink
Ce serait plutôt à lui d'effectuer cette fusion, non ? Qu'en pensez-vous ?

D'accord avec toi sur le principe.
Toutefois, c'est à lui de décider. Mais en lisant (mal ?) Permission levels for a user account repository je n'ai pas trouvé où cela se configure. Dans "Settings", par le propriétaire ?
Ceci en supposant que HH64 souhaite cette restriction.

Sinon, de mon point de vue, la bonne démarche est de créer le "Pull request" et d'attendre que d'autres (tous les autres ?) collaborateurs aient pu en tester les effets. Si tout le monde est d'accord, le "pull request" peut être mergé sans équivoque et sans froisser quiconque. Sinon, le dernier arbitre doit être HH64.
Vu que nous ne sommes que trois, cette discipline doit être facile à respecter, même sans restriction de droits.
Quand il y a de nombreux collaborateurs et que le responsable du projet ne peut pas ou ne souhaite pas tout gérer, il peut être utile que chaque collaborateur puisse "merger". Le principe à respecter peut alors être que le "merge" soit fait par quelqu'un d'autre que l'auteur du "pull request".
Cette procédure limite l'introduction de bugs ou fonctionnalités indésirables. Mais personne n'est parfait, il faut faire avec.

Il arrive qu'aucun autre collaborateur ne se sente assez compétent pour juger et merger un PR. Dans ce cas, soit on fait confiance et on merge après test superficiel, soit on attend l'arbitre... Qui sera peut-être aussi embarrassé...

Quand tout le monde est de bonne foi, les incidents sont rares, réparables. Cela s'arrange toujours.

Clm76 · 11/12/2021 13:15:24

dany93 a écrit :

Sinon, de mon point de vue, la bonne démarche est de créer le "Pull request" et d'attendre que d'autres (tous les autres ?) collaborateurs aient pu en tester les effets. Si tout le monde est d'accord, le "pull request" peut être mergé sans équivoque et sans froisser quiconque. Sinon, le dernier arbitre doit être HH64.
Vu que nous ne sommes que trois, cette discipline doit être facile à respecter, même sans restriction de droits.

Ok, d'accord avec toi. J'ai voulu tester la démarche jusqu'au bout. La prochaine fois, j'attendrai votre accord avant de "merger", ou HH64 ou toi le ferez.

Forum Flightgear France

Annonce

#201 8/12/2021 11:11:13

Re : Alouette-II (JSBSim twin engine)

#202 8/12/2021 11:17:58

Re : Alouette-II (JSBSim twin engine)

#203 8/12/2021 11:43:54

Re : Alouette-II (JSBSim twin engine)

#204 8/12/2021 12:05:32

Re : Alouette-II (JSBSim twin engine)

#205 8/12/2021 12:20:14

Re : Alouette-II (JSBSim twin engine)

#206 8/12/2021 12:26:12

Re : Alouette-II (JSBSim twin engine)

#207 8/12/2021 12:38:20

Re : Alouette-II (JSBSim twin engine)

#208 8/12/2021 12:40:08

Re : Alouette-II (JSBSim twin engine)

#209 8/12/2021 13:14:33

Re : Alouette-II (JSBSim twin engine)

#210 8/12/2021 13:39:03

Re : Alouette-II (JSBSim twin engine)

#211 8/12/2021 18:07:24

Re : Alouette-II (JSBSim twin engine)

#212 9/12/2021 12:58:08

Re : Alouette-II (JSBSim twin engine)

#213 9/12/2021 13:58:21

Re : Alouette-II (JSBSim twin engine)

#214 9/12/2021 16:21:35

Re : Alouette-II (JSBSim twin engine)

#215 9/12/2021 19:18:30

Re : Alouette-II (JSBSim twin engine)

#216 9/12/2021 19:29:17

Re : Alouette-II (JSBSim twin engine)

#217 10/12/2021 12:17:39

Re : Alouette-II (JSBSim twin engine)

#218 10/12/2021 16:51:36

Re : Alouette-II (JSBSim twin engine)

#219 10/12/2021 17:17:57

Re : Alouette-II (JSBSim twin engine)

#220 10/12/2021 18:20:27

Re : Alouette-II (JSBSim twin engine)

#221 10/12/2021 19:14:06

Re : Alouette-II (JSBSim twin engine)

#222 10/12/2021 19:53:21

Re : Alouette-II (JSBSim twin engine)

#223 11/12/2021 11:34:27

Re : Alouette-II (JSBSim twin engine)

#224 11/12/2021 12:53:53

Re : Alouette-II (JSBSim twin engine)

#225 11/12/2021 13:15:24

Re : Alouette-II (JSBSim twin engine)

Pied de page des forums