Projet G5

McColson a écrit : 13 déc. 2018, 19:27Oui c'est bien ça git, ou cloud, ou SVN etc... je me posais la question de la structure à adopter.

Bon, déjà SVN on oublie, en termes de gestion de version/outil collaboratif, on est dans l'antiquité, voire tout juste sorti de la préhistoire...
Cloud, en soi ça ne veut rien dire si ce n'est que tes données sont sur le serveur d'un inconnu (techniquement, github est un service cloud d'ailleurs), mais en gros, et sans être expert en la matière, je ne vois aucun service qui soit réellement adapté à ce genre de besoin.

McColson a écrit : 13 déc. 2018, 19:27J'essaye d'éplucher les différents tuto sur GIT et GITHUB pour comprendre les différents principes de base : organisation, branches etc... A moins que tu puisses nous éclairer vite fait.

La question piège ^^
git ça me parait super simple, mais je travaille avec au quotidien depuis des années, donc difficile à expliquer...

En gros, si on prend les choses dans l'ordre :

1. un repo (ou dépôt en bon français) git correspond à un projet. Donc ce que tu y met dedans dépend de ce que tu considères faire partie de ton projet, et comment tu le découpes :
- par exemple on pourrait imaginer avoir un seul git qui contienne le code de tous les logiciels d'un système linux complet
- comme ça fait beaucoup, on peut se dire qu'un repo par logiciel, c'est pas mal en fait
- quand il y a pas mal de données mixées, on peut choisir d'avoir plusieurs repo, par exemple un pour le code + les docs développeur, un autre pour les libs de composants (cf. kicad), et un dernier pour la doc utilisateur

Typiquement, si tu prends mon projet nanoTracer, j'ai un seul repo qui contient le code et les fichiers kicad ; c'est pas forcément optimal, mais comme c'est un petit projet, on s'y retrouve facilement. Pour un projet de type Arduino (la carte complète avec les alims embarquées, le microcontroleur etc...), on serait mieux avec un repo pour l'électronique, et un autre pour le code.

2. un repo garde l'historique du projet, donc chaque modif doit être enregistrée dans un "commit". Ça permet de savoir qui a modifié quoi, quand, et en quoi consistaient exactement les modifs ; on peut donc décider d'annuler un commit (en ajoutant un commit de "revert" qui va simplement restaurer les modifications initiales, tout en conservant l'historique), ou de revenir à un état antérieur du repo.
Cette notion de commit est fondamentale, c'est en gros l'équivalent git d'une transaction de base de données.
À noter que pour des grosses modifs, on va généralement faire plusieurs commits d'affilée, en les groupant généralement par fonctionnalité, ça rend l'historique plus gros, mais aussi plus lisible/logique/compréhensible.

3. les branches permettent de gérer les contributions simultanées, voire concurrentes, ou encore d'expérimenter des choses sans toucher à la branche de référence, censée être la branche "stable" du projet, généralement nommée "master" (d'où la règle number one : ne jamais travailler directement sur master)
Une branche est un instantané de l'état du repo à un instant T, sur laquelle on va ajouter nos commits sans impacter les autres branches. Plusieurs contributeurs peuvent avoir des branches de travail différentes et bosser dessus en même temps sans que personne ne se gène.

4. les branches vont forcément, au fil du temps, diverger entre elles, y compris par rapport à master. Il faut donc, une fois le travail terminé, fusionner ("merger" en bon franglais) la branche de travail dans master. git fait un boulot admirable en termes de fusion des modifs entre différentes branches et règle énormément de conflits automatiquement (au contraire de SVN qui était une plaie pour ça), donc il ne faut pas avoir peur de créer des branches pour bosser sur différents sujets en même temps.
LA bonne pratique : on crée une branche pour bosser sur une fonctionnalité, et une seule ! Une fois le boulot terminé, et avant d'attaquer autre chose, on merge (ou on soumet une "pull request" sur github pour demander au chef d'intégrer nos modifs), et on supprime la branche une fois le merge effectué. Si on doit bosser sur autre chose avant la fin du merge, on ne reste pas sur la même branche, mais on en crée une nouvelle à partir de master (sinon on prend aussi les modifs non-mergées, et là c'est un peu plus chiant pour le mainteneur).

McColson a écrit : 13 déc. 2018, 19:27Et selon ton expérience, comment il faudrait commencer à configurer le dépôt ?
- Un repository par bibliothèque : 1 pour kicad, 1 pour les fichiers 2D insckape, 1 pour le travail des pièces 3D pour la simulation 3D
- ou des branches par spécialités ?

Personnellement je verrais bien un découpage par "finalité" de fichiers : le vectoriel (inkscape) dans 1 repo, les pièces 3D "génériques" dans 1 autre, les composants 3D pour kicad dans un autre, pour les empreintes kicad (PCB) encore 1 autre, et les symboles kicad (schéma) dans 1 dernier.

Le fait que kicad ait ce genre d'organisation milite aussi dans ce sens, puisque en fonctionnant comme ça on reste compatible avec l'import de librairies via le plugin github de kicad

Bonjour,

Ce site ( anglophone ) peut, peut être, aider pour Git ( ou pas ).

Amicalement,
Grégoire

Merci chanmix51, je vais regarder ça !

Question peut-être bête, mais les fichiers 3D que j'utilise sous solidworks ou freecad, je les trouve souvent sur ces deux sites :
https://www.3dcontentcentral.fr/
https://grabcad.com/library
A votre avis sortir les fichiers les plus utiles pour nous et les mettre à dispo sur un github, ça pose pas de soucis de licence ou autre ?
J'avoue je suis une quiche dans ce domaine licence open, CC et autre. En taille de ballon je suis bien meilleur !

Question pour kicad, il faut à chaque fois la version .STEP et la version .wrl d'un fichier 3D ? J'ai cru comprendre que le WRL c'était mieux pour le rendu, y'a plus d'info...

McColson a écrit : 21 déc. 2018, 15:12 Question peut-être bête, mais les fichiers 3D que j'utilise sous solidworks ou freecad, je les trouve souvent sur ces deux sites :
https://www.3dcontentcentral.fr/
https://grabcad.com/library
A votre avis sortir les fichiers les plus utiles pour nous et les mettre à dispo sur un github, ça pose pas de soucis de licence ou autre ?
J'avoue je suis une quiche dans ce domaine licence open, CC et autre. En taille de ballon je suis bien meilleur !

Sauf cas particulier, à savoir l'auteur du fichier stipule explicitement que son contenu est sous une licence "open source compatible" (généralement CC BY-...), il est interdit de télécharger ces fichiers pour un usage autre que personnel, ce qui inclut la mise à disposition via github.
Donc non, on ne peut pas le faire, il faut forcément contacter l'auteur de chaque fichier et obtenir leur autorisation (voire obtenir l'autorisation de distribuer sous une licence libre, c'est encore mieux)

(je rêve du jour où l'open source sera la norme, qu'on puisse arrêter de s'emmerder avec ces conneries...)

Grrr ouaip bah c'est la loose du coup...
Au rythme où je modélise, dans 5 ans on y est encore...
ça ne coute rien de demander on verra bien... vu le peu de composants à référencer pour nos amplis et autres, et la portée d'un dépot github comme celui que j'envisage, ça serait balo que les mecs n'acceptent pas.

Et pour kicad, tu as une idée pour les modèles 3D ?

McColson a écrit : 21 déc. 2018, 15:55Et pour kicad, tu as une idée pour les modèles 3D ?

Non, j'ai jamais touché à ça

a-wai a écrit : 21 déc. 2018, 18:46

McColson a écrit : 21 déc. 2018, 15:55Et pour kicad, tu as une idée pour les modèles 3D ?

Non, j'ai jamais touché à ça

Ok je vais me faire un github perso/privé pour mes modèles 3D, je partagerais sous le manteau ... lol

a-wai a écrit : 11 déc. 2018, 10:49 Comme Pote Gui, je me suis fait mes librairies perso (dispos ici si tu veux un exemple).
Quand je crée un nouveau symbole, il va dans a-wai.lib (depuis l'éditeur de symboles tu peux choisir la librairie courante, et sauvegarder ton symbole dans cette lib, ou le sauvegarder dans une nouvelle lib il me semble).
Pour les empreintes, c'est encore plus simple, puisqu'il suffit de les mettre dans un dossier avec une extension .pretty, qui pourra alors être utilisé comme lib (et il me semble que pour les modèles 3D c'est similaire, mais pas sur, j'en ai jamais fait).

Tu gardes tout ça dans un dossier défini, dans ton /home ou ailleurs si tu as une partition de données (chez moi c'est /mnt/data/Git/kicad_libs), et tu peux ensuite ajouter ce chemin comme "User-defined search path".

Si j'ai bien compris, ta lib a-wai.lib elle est sur ton PC. Mais elle est synchronisée comment avec ton github ?
Tu fais pas ça manuellement, quand même ?!
J'ai commencé à mettre des empreintes sur le github, mais en fait si on veut faire une bilbiothèque PG5_kicad.lib par exemple, il aurait fallu que je sélectionne et que j'ajoute une par une les empreintes que je souhaite voir dans cette lib sur mon disque dur avant d'uploader ça sur github ?
Et du coup comment rendre ça collaboratif ?
(putain j'ai encore du taf pour comprendre tout ça)

McColson a écrit : 21 déc. 2018, 20:37Si j'ai bien compris, ta lib a-wai.lib elle est sur ton PC. Mais elle est synchronisée comment avec ton github ?
Tu fais pas ça manuellement, quand même ?!

Ça dépend de ce que tu appelles manuellement ? Je fais tout avec git (en ligne de commande parce que je suis un vrai geek, mais il y a des softs graphiques pour ça).
Une fois que j'ai fait une modif, je fais un commit puis un coup de push, et hop, magie, c'est sur github !

McColson a écrit : 21 déc. 2018, 20:37J'ai commencé à mettre des empreintes sur le github, mais en fait si on veut faire une bilbiothèque PG5_kicad.lib par exemple, il aurait fallu que je sélectionne et que j'ajoute une par une les empreintes que je souhaite voir dans cette lib sur mon disque dur avant d'uploader ça sur github ?
Et du coup comment rendre ça collaboratif ?

C'est l'idée oui.
Pour la collaboration, tout passe par les branches : tu crées une branche de travail, tu fais tes modifs, tu commit et tu push. Une fois que c'est bon, il faut "merger" ta branche de travail dans master (ce qui peut passer par une "pull request" sur github), et supprimer la branche de travail une fois que c'est bon.
Du coup chacun bosse sur des branches différentes (donc pas de conflits), et le tout est finalement fusionné dans master au fil de l'eau. Seul point de vigilance, il faut s'assurer que la copie locale du master soit à jour avant de créer sa branche de travail (ce qui correspond à un "pull" en jargon git).

Ok je commence à y voir plus clair (désolé j'suis suisse un peu), merci a-wai !
Bon bah y'a plus qu'à alors !
J'utilise github desktop pour windows en ce moment sur PC.
Donc d'abord il faut créer dans le master une PG5_kicad.lib pour que chacun puisse avoir le droit de faire une branche.
Chaque personne intéressée, récupère le dépôt en local sur son PC, et la modifie et fait sa branche ensuite.

Youpi je crois avoir compris

On commence par quoi a-wai (j'emmène le PC ce we je ferais mon bilbo au coin du sapin )
On rempli un peu le master avec ce qui existe dans les lib kicad officielles ?

(va falloir faire 2-3 tutos je le sens)

McColson a écrit : 21 déc. 2018, 23:18 Ok je commence à y voir plus clair (désolé j'suis suisse un peu), merci a-wai !
Bon bah y'a plus qu'à alors !
J'utilise github desktop pour windows en ce moment sur PC.
Donc d'abord il faut créer dans le master une PG5_kicad.lib pour que chacun puisse avoir le droit de faire une branche.
Chaque personne intéressée, récupère le dépôt en local sur son PC, et la modifie et fait sa branche ensuite.

Voilà, c'est l'idée !
(comme c'est une lib kicad, dans un repo dont le nom commence par kicad, tu peux te contenter de PG5.lib ou projetg5.lib )

McColson a écrit : 21 déc. 2018, 23:18 On commence par quoi a-wai (j'emmène le PC ce we je ferais mon bilbo au coin du sapin )
On rempli un peu le master avec ce qui existe dans les lib kicad officielles ?

Bof, les libs officielles sont dispos pour tous et généralement installées avec le soft, donc pas la peine de les remettre ici. Mieux vaut se limiter aux trucs spécifiques, créés par et pour nous, je pense.

Pour les libs officielles je pensais faire le tri pour sortir uniquement celles utiles pour nous. Un peu comme tu as fait sur ton github.

Hmmm, non, les seuls composants que j'ai dans mes libs sont soit des composants que j'ai créé, soit des trucs de la lib standard que j'ai modifié parce que les originaux ne m'allaient pas (ou, parfois, des composants récupérés sur le net et généralement modifiés pour mes besoins).
Ne pas oublier que tout ça date déjà de quelques années, ça peut faire doublon maintenant que les libs standards ont été étoffées, mais à la base ce n'était pas le cas (même chose pour le dossier "third-party", certains éléments ont pu être intégré dans le standard maintenant, je n'ai pas vérifié)

Bref, règle de base : éviter les doublons

Salut tout le monde,
Bon pour ceux que ça intéresse, je me suis tapé la Kicad Library Convention alias KLC.

Je pense que si on cherche à remplir le github avec des choses de qualité, c'est un truc à connaitre.
https://translate.google.fr/translate?h ... rev=search
(jptrol utile pour redessiner le symbole de la BTDR correctement)
Je m'occuperais de refaire l'empreinte et le package 3D.

J'essaye de faire un résumé en faisant une coupe franche sur les choses moins intéressantes, et mettre ça en forme sous forme de fiche A4 max

Je déterre le post parce que je cherche un fichier 3D pour des trimpot Piher 10 et 15mm qui fonctionnent sous Kicad. Car en effet, j'ai pu trouver des .step mais qui ne sont pas reconnus par Kicad (pourquoi ?)... Genre celui-là : https://grabcad.com/library/piher-pt-15v15-1

EDIT :
Je ne sais pas pourquoi mais j'ai dû enregistrer le fichier .step dans la librairie "package3d" de Kicad pour pouvoir visualiser le modèle... Je pige pas