Ce qui suit n'est vraiment qu'une suggestion, je ne suis pas entièrement sûr de sa pertinence, et n'étant pas développeur moi-même, je me garde bien d'avoir la prétention d'imposer quoi que ce soit.
Il apparaît clairement depuis un certain temps que de plus en plus de développements sont dépendants de près ou de loin de l'accomplissement de la ZEP-12. La ZEP-25 ne peut pas se faire sans, la ZEP-5, la ZEP-13, la ZEP-14, la ZEP-28 et sans doute d'autres seraient considérablement simplifiées et on éviterait du travail supplémentaire à la ZEP-11 ou encore la ZEP-22. Sans compter toutes les avancées mineures où l'on dit « ouais, mais quand même, ce serait con de le faire maintenant, alors que la ZEP-12 arrive bientôt ».
Seulement, malgré le travail admirable de pierre_24 et artragis, la ZEP-12 n'est pas encore finie, loin s'en faut. Il reste de gros morceaux, comme la publi et la validation partielle, et le rebase (si j'ai bien compris ce que c'est) va être colossal.
Alors je me demandais, maintenant que la v 1.7 vient de passer en prod, ne serait-il pas pertinent (souhaitable ?) que tous les développeurs qui ont les compétences nécessaires se consacrent entièrement à la ZEP-12 ? À l'exclusion des bogues bloquants et régressions, qui restent la priorité absolue, bien sûr. Cela générera nécessairement un délai d'adaptation pour tout le monde, mais est-ce que la ZEP-12 ne serait pas aboutie beaucoup plus vite si on a non pas 2 mais 5, 6 ou je ne sais combien de devs qui planchent dessus ? Et que ceux qui ne peuvent pas contribuer se donnent à fond sur la QA ?
L'idée n'est pas tant de terminer la ZEP en soi que de libérer le goulot d'étranglement sur l'avancement de tout le reste.
C'est une excellente idée. Pour la culture, en termes agiles ça s'appelle identifier et agir sur un goulot d'étranglement (bottleneck).
C'est extrêmement fréquent et ça donne généralement de très bons résultats. En termes "pratiques" mais aussi humains, ça soude plutôt bien de se retrouver tous sur une même tâche un peu galère.
Je ne peux pas parler pour pierre24 qui sera le responsable en ce qui concerne l'algo de base pour la publication.
Par contre, pour moi, je pense vraiment que la ZEP 12 est à deux semaines, peut être 3 de faire sa PR sur le dépôt officiel !
PR ne signifie pas "fin du code" mais "bon on n'a plus qu'à affiner les choses".
Globalement, aujourd'hui, ce qu'il faut vraiment faire, c'est passer partout sur la ZEP 12 et vérifier qu'on n'a aucune régression et que tous les bugs corrigés depuis la v 1.4 ont été corrigés dans la ZEP 12.
AUtre aspect, il va falloir décidé de ce qu'on fait pour la migration parce que là, c'est assez casse pied.
Je pense que la ZEP12 est assez mure pour accueillir du développement extérieur à pierre et moi, donc je suis tout à fait pour qu'on mette un max de ressource sur celle-ci.
PS: le rebase qui va être chiant sera le git rebase upstream/dev avec l'arrivée de django 1.7 j'ai pas mal de merde dans le dépôt et il semblerait que mon outil de merge soit merdique. Je veux bien de l'aide pour faire ça
PS: le rebase qui va être chiant sera le git rebase upstream/dev avec l'arrivée de django 1.7 j'ai pas mal de merde dans le dépôt et il semblerait que mon outil de merge soit merdique. Je veux bien de l'aide pour faire ça
Ce que tu peux sûrement faire c'est découper ton rebase par version, genre git rebase v1.5, puis git rebase v1.6, etc.
PS: le rebase qui va être chiant sera le git rebase upstream/dev avec l'arrivée de django 1.7 j'ai pas mal de merde dans le dépôt et il semblerait que mon outil de merge soit merdique. Je veux bien de l'aide pour faire ça
Si c'est plus simple, fais un merge et non un rebase. Déjà c'est beaucoup moins casse-gueule.
Quant au reste, peut-être qu'on peut se mettre à "plus" sur la ZEP-12, mais est-ce pertinent ? Je rappelle cette citation qui illustre très bien le propos :
Le chef de projet, c'est celui qui pense qu'on peut faire un enfant en un mois avec neuf femmes.
Le fait qu'il y ait goulet d'étranglement ne veut pas forcément dire qu'on peut éviter ce goulet en mettant plus de développeurs (découpage des tâches, formation, etc.)
Ce qu'il serait sans doute plus intéressant, c'est que les développeurs actuels de la ZEP-12 nous indiquent où ils ont besoin d'aide et ce qu'on peut faire pour les aider.
Si c'est plus simple, fais un merge et non un rebase. Déjà c'est beaucoup moins casse-gueule.
Ok, je tenterai ça ce soir ou demain.
Ce qu'il serait sans doute plus intéressant, c'est que les développeurs actuels de la ZEP-12 nous indiquent où ils ont besoin d'aide et ce qu'on peut faire pour les aider.
Comme je l'ai dit : principalement on a besoin de QA anti regression et si possible de gens qui codent quelques testes unitaires.
La documentation est déjà assez immense, les fonctionnalités sont nombreuses et la ZEP mature (en fait il ne manque "plus que" la publication et pierre a dit qu'il s'en occupait dès qu'il a du temps.
En ce qui concerne la proposition générale, dans le contexte bénévole de Zeste de Savoir, je ne suis pas certain que c'est une bonne idée. Les contributeurs travaillent majoritairement sur ce qu'ils ont envie de travailler (à quelques exceptions près parce qu'il faut quand même faire de la QA de temps en temps) et donc, la ZEP-12 n'intéresse pas spécialement tout le monde.
Par contre, la discussion semble tendre vers un focus des contributeurs à la pré-PR et la PR de la ZEP-12 et là, il y a des choses intéressantes. La release 1.8 approchant (dans sa phase de test sur le serveur bêta), nous pouvons tout à fait imaginer un freeze des merges sur les autres PR comme nous l'avons fais pour Django 1.7 en mettant toutes les ressources sur la QA de la ZEP et sur les correctifs à apporter. Cela me semble même nécessaire parce que faire constamment des rebase, c'est très chiant.
Dès qu'on me donnera le feu vert, j'arrêterais mes autres contributions pour me focaliser sur des tâches de la ZEP 12. artragis et pierre-24 n'auront qu'à me dire quoi faire.
Globalement le feu vert est déjà là, mais il sera "officiel" quand pierre aura eu le temps de faire la publication !
Va falloir améliorer votre communication alors parce que je l'ai vu nul part.
Il faudrait que vous écriviez de la documentation pour savoir comment fonctionne votre nouveau module, comment migrer des tutos (j'ai cru comprendre que tu avais codé un premier jet d'un script) et créer des issues sur ton dépôt ou celui de pierre pour savoir qu'est ce qu'il reste à faire.
Va falloir améliorer votre communication alors parce que je l'ai vu nul part.
Bah le principe de "il est pas encore officiel" c'est que à part rapidement dans deux/trois topics où j'invite les gens à venir tester, il n'est pas annoncé en grand et en visible.
Il faudrait que vous écriviez de la documentation pour savoir comment fonctionne votre nouveau module, comment migrer des tutos (j'ai cru comprendre que tu avais codé un premier jet d'un script) et créer des issues sur ton dépôt ou celui de pierre pour savoir qu'est ce qu'il reste à faire.
Sauf pour les issues, tout a déjà été fait. Quand je dis que la documentation est énorme, c'est qu'elle l'est vraiment.
si tu fais un clone de mon dépôt, puis que tu vas dans :
1
2
3
cd doc
make html
firefox build/html/back-end/tutorialv2.html
et tu auras toutes tes infos dans la partie Passage des tutos v1 aux tutos v2.
Bordel de m***, je sais pas ce qu'on bouffé les gens aujourd'hui, mais j'en veux aussi, ça discute de partout et je suis pas encore arrivé au bout de tout ce qui est arrivé aujourd'hui, y'a trop, overflow.
Bref, je vais essayer de par répéter ce qu'artragis a dit, mais si c'est le cas, désolé.
Premièrement, la comm': on en a pas. On fait des annonces sur le topic de la ZEP-12, et lit qui veux, mais c'est "caché" là bas. ZdS est assez mal foutu pour la comm' de cette importance ! (exemple, si Eskimon m'avais pas appellé ici, je serai à mon avis passé à coté). Je pense que j'ai dis de temps à autre que toutes propositions/issues/QA/PR étaient les bienvenues, mais voilà, comme l'as souligné Andr0, les dévellopeurs n'en fond qu'à leur tête et c'est très bien comme ça (entendez par là que je ne tiens pas à ce que quelqu'un se sente "obligé" de faire du code qu'il n'as pas envie de faire). Preuve en est, je ne fais pas "que" de la ZEP-12.
Du reste, j'aurais tendance à être un petit peu moins optimiste que mon collègue sur l'échelle de temps, mais ça doit être parce que je connais mon emploi du temps. Typiquement, la publication, ça risque de me demander un weekend (ou l'équivalent étalé sur le temps libre de ma semaine, selon), parce que c'est pas facile et que je sais pas à quel point on a réellement avancé dans le back coté validation (je veux dire par là que les classes existent, mais qu'elles sont pas forcément reliée à des templates dans le front et qu'on a pu passé à coté d'un truc). Bref, pour faire ça bien, je vais prendre un peu de temps (d'autant que je suis "bloqué" par la MàJ vers Django 1.7 pour m'éviter de foutre plus le bazar dans ce rebase immonde qu'est celui d'artragis).
Du reste, si quelqu'un se sens d'humeur à nous aider, y'a, au delà des gros points que sont la publication et la migration, plusieurs petits points à régler, parmis lesquels la ZEP-03, l'édition simultanée, la mise en bêta (qui est pas encore tout à fait parfaite), des issues marquées ZEP-12 pas trop longues/chiantes à faire, et de manière générale de la QA (mais personne n'aime la QA). Puis, si quelqu'un pouvait une fois lire le code et dire "bordel, vous avez fait de la grosse merde, là", ça ferait mal à mon égo, mais ça serait sérieusement utile. Le but étant au final de raccourcir l'étape de la PR finale si plusieurs personnes sont déjà passées sur le truc. Mais n'y voyez aucune obligation, hein
Je vais conclure sur une remarque générale que j'ai faite à un moment, mais pas au bon endroit et pas au bon moment:
Bon, pour apporter ma pierre à l'édifice (jeu de mot pourri), on est face à un cas inédit dans l'histoire de ZdS: le refactoring d'un module complet. On ne c'est jamais mis d'accord sur les règles à appliquer, et à vrai dire, je fais comme il me semble le mieux (mais je n'ai aucune expérience dans le dev' de projet) et je laisse artragis gérer sa branche comme il le sens, parce que c'est la sienne et que je me vois mal faire des PR de "mise à niveau" (effectivement, il remet parfois à jour avec dev, par contre, à ma connaissance, on a encore rien remonté de là dans le nouveau module, on en est toujours à adapter de l'ancien code). Bref, peut être que tout ça mériterai une discussion bien cadrée et une réponse claire et nette.
Puisque cette discussion n'aura à mon avis pas lieu (elle arrive trop tard et on a d'autres choses plus importantes à faire de ces temps-ci sur le dev' de ZdS), gardez bien en tête qu'à un moment, il faudra qu'on fasse un retour sur ce qu'à été le développement de cette ZEP pour en tirer les conséquences, et à mon avis, il faudra qu'on commence par le faire artragis et moi-même (une sorte de rapport). Je pense que ça aidera le développement de ZEP futures et de manière générale le développement de ZdS lui-même. Le fait qu'on a maintenant un CdS va peut être aussi changer la donne.
J'ajoute aussi,
Par ailleurs, et je crois l'avoir déjà dit plusieurs fois, ne sachant absolument pas quel est mon emploi du temps ou le temps libre dont je dispose, n'étant absolument pas du genre à me mettre la pression pour ça (sinon je fais n'importe quoi) et laissant artragis travailler comme il l'entend (c'est la moindre des choses), je (nous) ne sais (savons) pas prédire quand la ZEP-12 sortira vraiment. Je sais ou on en est, parce que je garde un oeil dessus et que j'ai en tête les gros point par lesquels ont devra passer. Par contre, et c'est peut être paradoxal, je ne veux pas être un frein au développement de ZdS dans les modules correspondants.
Bon, je sais pas encore quelle sera ma motivation mais ce week-end en journée je serais dispo (disons dans l'intervalle 9h-16h). Si je peux vous aider (même pour de la QA) dites le moi, ma seule contrainte étant : pitié faites que ca passe avec Django 1.7 car je veux pas m'amuser a basculer mes requirements sans arrêt.
La ZEP-3 ca sera peanuts normalement. Elle est hyper découplée du modèle des tutos si mes souvenirs sont bons, donc ca devrait pas trop mal se passer.
Le fait qu'on a maintenant un CdS va peut être aussi changer la donne.
Tu veux dire CdP ?
Du coup si ce weekend vous bosser dessus, je serais sur IRC
Je mettrai à jour au fur et à mesure que je découvre des bugs.
J'ai mis les tags qui vont bien (Question quand c'est encore en suspend, Help Wanted quand on aurait bien besoin d'un coup de main) et j'ai assigné pierre ou moi même aux taches que nous avons déjà prévu l'un et l'autre.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
