Saluton Anne,
Pas la peine de me solliciter en particulier puisque c’est moi qui propose cette traduction de la licence en espéranto .
Quant à Pascal, je le verrai à Béziers durant ce mois d’août et je pourrai lui demander son avis.
Amike,
Yves
Excellente traduction (que j’ai lu très attentivement)…
De la part de Yves, je ne pouvais pas m’attendre à moins ! Bravo !
Du coup je me suis permis de fusionner la traduction EO, si des erreurs de traduction persistes, n’hésitez pas a le signaler ici ou dans une issue du dépôt de la licence
C’est valable pour toutes les traductions d’ailleurs
Quelqu’un pour reviewer l’amélioration de la traduction EN ? @Moul, @HugoTrentesaux ou @jytou peut-être ?
Lu en diagonale, ça me parait correct en Anglais et ça m’a permis de trouver quelques typo en français, cf MR.
J’ai fait un ajout concernant la nécessaire mise à disposition de la licence Ğ1 dans les logiciels / applications qui utilisent la Ğ1 (par exemple impossible de trouver la licence Ğ1 dans Cesium « à propos », alors que la licence du logiciel s’y trouve.
(Bon ok j’ai vu qu’elle était dans l’onglet « monnaie », mais il pourrait y avoir aussi un lien dans le « à propos »).
Par contre j’ai pas la main sur le dépôt, donc j’ai fait un commit, je crois, bref, enfin je pense que je pourrais avoir la main sur ce dépôt !?
Je t’ai passé « developer » sur le dépôt. Par contre, passe toujours par une MR pour qu’au moins une personne valide tes changements. C’est vrai pour tout le monde. Ça peu éviter, par exemple, l’erreur qui s’est produite durant ce live. À savoir, ajouter une seconde fois la même information.
J’en profite pour “upper” le post que j’ai fait sur l’architecture social de contribution de zeromq : Architecture sociale de contribution
Git est compliqué, et pour éviter que les gens galèrent, ils :
- n’utilisent pas de branche sur le dépot principal
- ont une seule branche master qui est toujours fonctionnelle
- les développeurs passent par un fork / merge request (même les développeurs principaux)
Specs de ZeroMQ :
The project SHALL have one branch (“master”) that always holds the latest in-progress version and SHOULD always build.
This is redundant because every patch always builds but it’s worth restating. If the master doesn’t build (and pass its tests), someone needs waking up.
'll come to branches soon. In short (or “tl;dr”, as they say on the webs), branches make the repository too complex and fragile, and require up-front agreement, all of which are expensive and avoidable.
To make a stable release a Maintainer shall tag the repository. Stable releases SHALL always be released from the repository master.
Tout à fait, c’est une excellente sécurité, la preuve !