We exchanged a few emails between developers since I arrived, but I believe a mailing list would be better (at least for developers, forums are probably better for users):

1) We don't need to know everybody, all registered people will receive mail
2) We will have access to mailing-list archive (much better than forums in the long term)
3) It will be easier to submit patches (for instance with git-send-email), when people are not comfortable enough to access directly a git branch, or just want an advice on a possible gir patch. The current forums format does not allow clean posting in text mode (important for patches, where every space is important).
4) No need to be on-line to view messages (if already received) or to reply (they will be sent later).

Tuxfamily offers mailing-lists management I think:
    https://faq.tuxfamily.org/MailingLists/En

So our beloved admin(s) could just create a "devs" list, with writing access disabled before a member is allowed by an admin, archives available to public (I don't think discussions should be hidden), et voila !

I am not sure how the spam control is working at tuxfamily. If good, inscription (writing) could be public.

Please remember an issue I have noticed with other mailing-lists: We will need a few users from gmail, gmx, yahoo, etc... to verify that emails coming from the list are not in SPAM (SPF/DKIM signatures could be a problem depending their handling by tuxfamily). Torvalds did complain a lot with Google (he uses gmail) when he noticed all kernel emails were in spam after a change on gmail server side (corrected since then, at least for him).

What do you think ?

---

Rectified by bodiccea 23/01/2017 09:59

Envoyer du texte ascii en fonte "courier" ou équivalent (hors pièce attachée) est impossible sur le forum. Du coup, une réponse non top-postée, toujours en ascii ne me semble pas possible non plus...

Voilà ce que donne un .txt:
---------------------------------------------------------------

GIT workflow

CURRENT SITUATION

Our current git workflow is the following:
- Master is the development branch, and is therefore not considered as "stable"
- There is no branching, no tagging.
- The only "pseudo-branches" are the local copies of master on developer machines.

This can be represented as:

Dev 1 local --- dev---------------------etc..
           /                 
          /pull        merge   merge
         /                     
Master--------------------R1--R1------R2------------------
                   /          /             /
           pull   /merge     /merge  pull  /merge
                 /          /             /
Dev 2 local  --- dev------------------------ etc...

The releases R1 and R2 are simply a snapshot (but untagged) of the development (master) branch, used to build the different OSes packages. In fact, there is no way of finding back any released version (so that an archive of source files is also generated together with packages). You will notice the 2 "R1" releases. This happens currently when some bugs are found in a release: a quick fix is made, and the "same" R1 is released (meaning that different users with "same" R1 release have in fact 2 different versions, as we can see on the user forum. It should be emphased that what differenciate versions is (and only is) a string manually managed in source code.

POSSIBLE IMPROVEMENTS ON RELEASE NAMING

Without changing current workflow, we could imagine two ways (between others) to have better version numbers:

1) Any Rx release could be unique (i.e. we cannot have 5.00.02 twice with different source code), and any Rx is a GIT tag. Many possibilities here:
 - We keep current naming and add some information (4th number, or timestamp):
   5.00.02-01, 5.00.02-02, etc...
   or:
   5.00.02-20170130-15:32, etc.
 - We change current version numbering, the second number being the release, and the third number a patch number:
   5.02.01, 5.02.03, etc...

2) To avoid source code change for versionning, we could use ant/git to:
 - have the version directly included in build.xml (given that the developer has the "git" command)
 - generate automatically a "version.java", which would contain only the specific build version information (version, maybe a few others: date, person making the build, etc...). A few different possibilities here (given we use only ant), one of them being: We could use a "template" source, and use the ant "replace" function to replace some tags (for instance: @@GIT-VERSION@@, @@BUILD-DATE@@, etc...).

Advantages:
 - We would know exactly which version a user is using, and, more important, we could easily "git checkout" the same version, to reproduce the issue with the exact same build.
 - The version number would be in only one place (the GIT tag)
 - No manual change in source code and build.xml

Drawbacks:
 - The version number is highly "static" and manually managed (as GIT tags are).

POSSIBLE IMPROVEMENTS ON WORKFLOW (REPOSITORY SIDE)

Dev 1 local --- dev---------------------etc..
           /                 

Oh. Et il en manque la moitié en plus...

Effectivement c'était pas joli, j'ai été obligé de reformater le texte, sinon ça semait la zizanie. As-tu essayé de poster en HTML? Non, oublies ça, le fait qu'il en manquait un bout indique que le taille maximum du message a été atteinte.

Tu as une solution?

Même si la taille passait, le html ne collerait pas, puisque le document final est un txt.
Le mail est tout a fait adapté aux discussions techniques. De plus il permet de soumettre des patches (par exemple aux débutants qui ne veulent pas toucher directement à GIT).

En attendant, je renvoie le document sur la liste...

Personnellement, je serais plutôt pour utiliser des pages. Au travail, nous utilisons Confluence pour stocker notre expérience et discuter.D'ailleurs, j'ai déjà créé une page pour ostorybook, expliquant comment ajouter une colonne dans une classe.Que ce soit mailing list ou forum, les choses sont hachées en messages, alors qu'une page présente l'aspect actuel (final , ) de l'information.

Je viens de PUSHer mes dernières modifs. J'en ai profité pour ajouter dans le dossiers doc le manuel (en fr et en en) ainsi que je projet de site web (en fr seulement). Les fichiers sont, pour la base, des fichiers oStorybook (donc mv.db) avec les images (dossiers img).

On pourrait créer un sous-dossier doc/dev et y mettre les documents sur lesquels tu travailles. Ainsi avec GIT on peut récupérer les mises à jour et y travailler. Combiné avec ta suggestion de créer des branches, ou des tags, on obtiendrait là quelque chose d'assez sympa.