Quand je connais l'auteur, il m'arrive de faire confiance, parce qu'il sait que j'attends des PR de qualitay :-)
Un PR n'est qu'un outil collaboratif, comme d'ailleurs hg, git, etc. Ensuite il faut s'entendre sur la "façon" de les utiliser et il n'y a ni de bonne ni de mauvaise méthode, seule compte celle qui fait consensus. Je sais que notre méthode de dév. dans DC, n'est pas "orthodoxe" selon les standards de X, Y ou Z, pas plus d'ailleurs que la présentation du code, mais elle a le mérite d'avoir produit un résultat viable, visible et pérenne depuis quelques années, ce qui est, à mon humble avis, la preuve qu'elle n'est pas si mauvaise. J'ai dit à plusieurs reprises ce que j'attendais des PR, ça n'a pas varié depuis. Maintenant on peut remettre ça sur l'établi et trouver une meilleure façon de faire, je n'ai pas de religion toute faite dans ce domaine (de l'avantage d'être un pur autodidacte dans ce domaine). Tiens, maintenant que j'y pense, on pourrait faire un atelier-débat autour de cette problématique le 21 septembre ! Moi, je kifferait bien d'avoir des avis différents (et parfois divergeants). Le 6 septembre 2013 11:42, Nicolas <[email protected]> a écrit : > Le 6 septembre 2013 11:19, Franck Paul <[email protected]> a > écrit : > > > > > > Pour moi un PR sur le dépôt officiel veut dire que l'auteur considère que > > ça peut être intégré à DC, et donc a priori testé. > > > > Tu ne testes pas en local avant d'accepter une PR ? Si demain un inconnu te > propose une PR tu vas tester ou au moins ne pas valider juste après. Je ne > comprends pas ta remarque. Pour moi une PR c'est une proposition de patch. > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
