search

fbiville / annotation-processing-ftw

Devoxx '15 hands-on lab - Annotation Processing: @​Nailed("it")
MIT License
5 stars 5 forks source link

Git-eries #3

Closed fbiville closed 9 years ago

fbiville commented 9 years ago

Je propose qu'on fasse 1 exo = 1 PR. 1 PR sera toujours composée de 3 commits :

  1. README complété
  2. exo à trou + test(s) U
  3. solution

On ne merge jamais, on rebase tout le temps.

Le premier commit sera ensuite fixup-é pour n'avoir qu'un commit initial unique de README. Il restera ensuite à tagger tous les commits qui introduisent les nouveaux exos (voire aussi un tag pour les solutions).

@lesaint : WDYT?

lesaint commented 9 years ago

sur le principe, ok, mais je vois d'autres sujets de PR que les exos, en vrac:

lesaint commented 9 years ago

ok, je viens de voir #4, l'idée de l'image docker est bien meilleure (et portable) mais il faudra ship les binaires docker alors

fbiville commented 9 years ago

@lesaint le plus pénible dans l'histoire, c'est de créer les tags, car on fait des incessants allers-retours sur les exos, si bien qu'on ne peut tagger qu'au dernier moment. L'idée ici est d'avoir une convention sur les exos (i.e. séparation en 3 commits) histoire de faciliter le boulot sur le tagging final (en plus de pousser à avoir un historique propre). Ça empêche pas d'avoir des PR pour le reste (de manière générale, je pense qu'on a intérêt à bosser par PR).

lesaint commented 9 years ago

J'avais sauté la partie sur les tags dans la description.

Que je comprennes bien, tu veux que les utilisateurs sautent de tag en tag pour aller d'un exercice à un autre ?

J'imaginais plutôt donner le repo complet, organisé au niveau répertoire et fichiers par niveau et exercices. Les README.md à chaque niveau de répertoire donnant les directives, explications et ressources.

Il est vrai, si on donne tout d'un bloc, qu'il se pose la question des solutions. Pourquoi ne pas utiliser une branche soluce ou cheat-mode avec le contenu de master plus les solutions ?

Ca me semble plus simple, car ça lève la contrainte sur l'ordre des commits et des merge des PRs. On s'évite un boulot à faire forcément au dernier moment.

Ce qui n'empêche que bosser par PR me semble la bonne approche (en particulier pour le processus de revue).

fbiville commented 9 years ago

L'avantage d'utiliser des tags, c'est que la situation initiale de chaque exo est bien celle qu'on attend, nous. Le problème, c'est que si les gens commencent à faire n'importe quoi (genre toucher du code qu'ils doivent pas modifier) et se plomber pour tout le hands on.

lesaint commented 9 years ago

pour reset, il suffit d'avoir un tag sur le dernier commit au moment où on livre pour la présentation, non ?

les participants pourraient feature-branch pour chaque niveau ou même exercice. Limite on les crées à l'avance dans le clone local.

lesaint commented 9 years ago

là que je viens de commencer à coder des exos, je me dis que l'on devrait mettre en place la solution docker rapidement.

Je crains la perte de temps que ça pourrait engendrer si on découvre à la fin que tel ou tel exercice ne tourne pas avec notre setup docker.

Si on met en place le setup docker par contre:

@fbiville, qu'en penses-tu ? des problèmes que je n'ai pas vu à mettre en place rapidement docker ?

fbiville commented 9 years ago

non tu as raison, je commence la dockerisation de suite.