Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    sfcwallace
    @sfcwallace

    Salut,
    je suis d'accord pour l'idée de se diviser en équipes afin de faire toutes les fonctionnalités.
    Par contre je ne pense pas que de se diviser en 4 équipes de 2 soit pertinent qu'on voit que la complexité varie d'une fonctionnalité à une autre. David et Béatriz ont confirmé hier que c'est surtout les fonctionnalités 1.2 et 1.3 qui sont pas mal les plus complexes implémenter.
    De ce fait je propose que:

    • une équipe de 4 personnes travaille sur les fonctionnalités 1.1 et 1.2
    • une deuxième équipe de 4 personnes travaille sur les fonctionnalités 1.3 et 1.4

    Par ailleurs je suis d'accord pour avoir un team leader par équipe pour assurer la communication et l'intégration de toutes les fonctionnalités à implémenter.

    À part ça je n'ai pas de commentaire sur le reste du plan.

    David Lauzon
    @davidonlaptop
    @francois-boyer : est-ce que je dois lire entre les lignes ? :-p
    karim73
    @karim73
    D'Accord sur le plan d'actions.
    karim73
    @karim73
    1- faudrait p-e mettre en place un plan controle/qualité pour s'assurer que la premiere phase (debugage du code plink pour identifier/comprendre les algos de chaque foncitionnalité) soit bien reussi, car on n'est pas nombreux a etre a l'aise avec le C/C++
    singemanator
    @singemanator
    Salut, concernant le plan à adopter, je suis plus de l'avis de Khaled. La complexité de chaque fonctionnalité ne sont pas égales. Donc, il serait plus efficace que l'équipe soit divisé en sous-équipe de 4 personnes où chaque équipe s'occupera de migrer 2 fonctionnalités. De plus, la planification des rencontres avec l'ensemble des membres de chaque sous-équipe va être plus facile. @karim73 qu'est ce que tu proposerais comme plan de contrôle/qualité? Et tu es d'accord sur quel plan d'action exactement?
    karim73
    @karim73
    j'ai pas eu le temps d'enumérer le reste des points :
    1) Concernant les inputs a utiliser pour les tests, chaque team pourrait utiliser les outputs generés par plink.
    2) a mon avis, il faudrait composer les teams par skills. Premiere etape importante est de debuger le code source plink pour extraire les fonctionnalités a implementer en scala. Assigner cette tache a quelqu'un qui a peu de connaissance en C/C++ n'est pas productif et on risque d'obtenir des spec de faible qualité ( d'où la mise en place d'une procedure de controle/qualité).
    3) que pensez vous de mettre en place un wiki scala, et un autre spark, pour qu'on partage ce qu'on a appris.
    4) Reste que le premier step primordial est de pouvoir compiler/executer ploink 1.9, moi personnellement j'Ai encore de la misere sur mon ubuntu 12.04 et mon mac yosemite
    singemanator
    @singemanator
    Je suis d'accord avec ce que tu proposes @karim73 . J'ai envoyé un message à l'un des co-développeur de Plink. Il m'a dit qu'il n'utilisait pas d'IDE mais plutôt Emacs pour l'édition. Et pour débugger, il utilisait des "printf". Il m'a aussi dit que c'est tout ce que j'avais besoin pour un outil en ligne de commande comme Plink...
    Aboubakary
    @Aboubakary
    Salut; je me joins à la proposition de faire plutôt deux équipes au lieu de quatre. Tout comme Karim73 l'a dit, le premier pas nécessaire pour avancer, qu'est la compilation n'est pas franchi. C'est après ce niveau que la division en deux équipes sera pertinente.
    ikizema
    @ikizema
    Excellente initiative @singemanator pour l’échange avec les développeurs de Plink. Avec ces infos, je suis encore moins certains de pouvoir utiliser un beau outil de debug comme ce que nous essayions de faire la semaine dernière.
    ikizema
    @ikizema

    Pour la stratégie organisationnelle à prendre, je suis un peu plus partagé. En effet, chaque des stratégies a ses avantages et ses inconvénients. Nous sommes pas suffisamment avancées pour déterminer las stratégie pour l'ensemble du projet. Je propose avancer par les petits pats sur les livrables v0.1.

    Avant tout, l'avancement actuel est le suivant pour les livrables v0.1 :
    I. Getting started Done (reste à compléter la tache dans waffle)
    II. Recette pour compiler plink Done pour Ubuntu 12.04
    To do pour Mac
    III. Implementation –make-bed To do
    IV. Implementation --genome Part1 To do
    V. Command-line (CLI) option parser for Scala To do
    VI . Use a dependency manager to build the project Done Initialisation of Maven project

    Rq : la tache VI était initialement dans v0.2, j'ai pris l'initiative de la mettre en v0.1 car la mise en place d'un projet de travail avec l'organisation de la gestion des descendances me semblait nécessaire pour les taches III et IV. Bien entendu, le projet est initié mais ne comporte pas encore l’ensemble des dépendances qui seront importés au fur et à mesure de l’avancement.

    Les mini taches :
    Tache I – Gestion de projet, reste à mettre en forme les commentaires de la tache sur ce qui a été decidé ou en cours de decision.
    Tache II – Protocoliser l'utilisation des outils pour compilation de plink sous Mac.

    On est 8, je prose de vous repartir sur les taches plus complexes à réaliser (j'estime la difficulté en mettant plus ou moins de personnes à la tache) :
    Tache III – équipe A de 3 personnes
    Tache IV – équipe B de 3 personnes
    Tache V – équipe C de 2 personnes (pour ceux qui ne souhaitent pas faire C/C++ pour le moment)

    Que pensez vous de cette démarche ? Si vous êtes OK, je vous propose de vous repartir en s’assignant la tache dans waffle en respectant les limites des groupes. Je me mets dans l'équipe A pour initier le mouvement.

    Voilà, dites moi si cela vous semble correct pour commencer.

    Ivan

    David Lauzon
    @davidonlaptop
    PVI. Vous pouvez linker les issues GitHub avec le préfixe dièse: #3, #4, #5
    ce qui permet un mouseover sur les issues
    sfcwallace
    @sfcwallace

    Salut, j'ai essayé avec pas mal de IDEs pour le debug (avec gdb) mais je n'ai pas réussi à le faire. En contactant le développeur qui fait la version 1.9 de plink il a confirmé à Karen qu'il se contente de mettre des printf() dans le code. Ce n'est pas du tout efficace mais quand on n'a pas le choix on fait avec.

    Pour le partage des équipes je suis de avis @ikizema pour démarrer l'implémentation.

    Je souhaite être dans l'équipe B

    singemanator
    @singemanator
    Salut, je vais faire la "recette" pour compiler Plink sur Mac. Et je vais me mettre dans l'équipe C.
    Alain April
    @aapril
    est-ce que les autres membres, qui n'ont pas encore communiqué, peuvent nous dire ou ils vont s'impliquer activement?
    Aboubakary
    @Aboubakary
    Salut, je dirais B
    karim73
    @karim73
    @ikizema , le depot plink1-9 contient deja un executable fonctionnel ( donc pas besoin de compiler).
    ikizema
    @ikizema
    @karim73, selon moi, pour faire l'exercice de rétro-ingénierie de PLINK, l'objectif n'est pas uniquement utiliser l’exécutable mais bien comprendre le code source et la manière dont il est compilé. Mais je peux me tromper...
    Update pour la tache #2 :
    La tache est presque terminé, reste 1 point semi-bloquant exprimé dans la tache. Si quelqu’un a la réponse, n'hésitez pas à mettre à jour l'info.
    francois-boyer
    @francois-boyer
    Moi je serai dans l'équipe C.
    sfcwallace
    @sfcwallace
    @karim73 en fait si on souhaite comprendre comment fonctionne le code pour les fonctionnalités à migrer le fait de pouvoir compiler le programme peut nous aider. Le développeur utilise des printf pour faire le "debug". Donc oui pouvoir le compiler pourra aider à comprendre le code source si tu souhaite modifier le code
    singemanator
    @singemanator
    @francois-boyer j'ai crée 4 sous-tâhes pour faire le parser de commande. Les 3 premières peuvent se faire en parallèle. La dernière sous-tâche est celle de l'implémentation. Regardes ce que tu voudrais faire.
    ikizema
    @ikizema
    Bonjour, j'ai ajouté différents espaces de communication pour organiser un peu nos échanges. Les noms sont évocateurs : Administratif (toute communication touchant l'organisation, espace de travail...), DataFormat (pour ce qui est de format de donnés) et Fonction--genome (pour tout ce qui concerne la fonction --genome lol). @francois-boyer, sauf erreur, on est en attente de ton acceptation sur github, as-tu bien reçu l'invitation ? N’hésite pas en cas de problème.
    singemanator
    @singemanator
    excellent. Je vais crée un autre forum pour le parser CLI
    karim73
    @karim73
    maintenant on a un chat room par activité/tâche ?
    ikizema
    @ikizema
    @karim73, pas par tache mais par famille de taches. Cela permettra de communiquer plus clairement sans mélanger les sujets. Une question administrative -> Administration, question concernant le format de donnes -> DataFormat...