J'ai des petites questions auxquelles, je n'ai pas trouvé de réponses sur la feuille de route
o Jusqu'à quand peut-on faire des livraisons importantes? (Et donc considérer que la BSF est "completement" fini d'un point de vue dev)
o A partir de quand passe-t-on en test intensif de la version BSF avec remontée des bugs dans bugtracker + correctif par l'équipe?
o Quand livre-t-on une première version stable 1.6 + test?
o Quand livre-t-on la version release 1.6.0?
Des fois, on parle du 10 avril ou du 15 avril? Mais quel version (la 1.6 la release 1.6.0)?
Je suis un peu perdu...
Hors ligne
j'ai hâte de la voir arriver pour faire les premiers test !!!!
Hors ligne
Voici ce que j'avais prévu, et ce que je propose à l'équipe de développeurs/testeurs : le 2 avril 2006, 23h59 création de la branche 1.6 dans Subversion. A partir du 3 avril 2006, on prépare la release 1.6.0RC1 sur la branche 1.6 tout en reportant les corrections sur trunk (alias BSF). Ce serait bien que vers le 15 avril on puisse sortir la 1.6.0RC1. Ensuite on attend les retours des testeurs, on corrige, on sort une RC2 (minimum 1 semaine après). On attend les retours, on corrige, on sort une RC3... jusqu'à ce que la stabilité soit satisfaisante au point de sortir la 1.6.0. Dans l'idéal, environ au 15 mai 2006, ce qui me semble ambitieux, mais réalisable.
La date du 15 avril correspond à la date anniversaire de la sortie de la 1.0.0, mais nous n'y arriverons pas, tant pis, c'était juste symbolique.
Concrètement, il reste une semaine complète et un WE pour finir les gros developpements. Attention, la sortie des releases est basée sur une roadmap temporelle et non fonctionnelle. Cela signifie que personne ne s'est engagé à ce que telle fonctionnalité soit présente en 1.6.0. Si une fonctionnalité n'est pas en 1.6, elle sera en 1.7, ce n'est pas grave. Par exemple, je suis à 50% du développement de la classification par tag, si je n'ai quelque chose de correct à la fin de la semaine, je ne garderai pas la fonctionnalité pour la branche 1.6. On ne met pas de fonctionnalité bancale sur une branche stable.
Rub, est-ce que je réponds à tes questions ?
Hors ligne
z0rglub a écrit:
Rub, est-ce que je réponds à tes questions ?
C'est parfait!
Cette semaine, je m'attache à faire une version stable de la NBM. J'ai plein d'idées + les votres, mais tout ne pourra pas être fait dans un 1er temps. La fonction actuelle fonctionne, il me reste à tester avec de la charge, à optimiser. Et si j'ai le temps, l'inscription à la liste pour la notification sera suivi d'un envoi de mail (mais c'est à voir avec le temps)
Hors ligne
J'ai essayé de me remettre dans le code ce weekend car j'avais un peu de temps mais je n'ai pas pu faire tout ce que je souhaitais. Notament je n'ai pas eu le temps de regarder le bug sur les sessions sur free.
Il y a un truc qui m'a géné en faisant un upgrade. Il y avait des choses qui ne fonctionnait pas. Je développe avec un niveau d'erreur maximal (2047 avec php4, 4095 avec php5) c'est-à-dire affichage de toutes les erreurs y compris avertissements (notice en grand breton) et sur certaines parties de code il y avait des notices notament avec l'utilisation de array_merge sur le script admin/site_update.php. Désolé je n'ai pas eu le temps d'investiguer plus profondément.
Je ne connais pas bien votre façon d'utiliser subversion. Pour ma part, j'essaie de ne pas commiter des trucs cassés pour ne pas géner les autres. En revanche lorsqu'on fait des développements relativement long cela peut être génant de ne faire qu'un seul commit surtout lorsqu'on développe à plusieurs endroits. Je développe pour ma part soit chez moi, soit sur mon portable (non connecté). Mes "trucs cassés" étaient sûrement dû à une mise à jour entre deux commit sur un long développement. Ne pourrait-on pas prévoir la création de branches "personnelles" pour ce genre de chose qui permettraient de faire des commit plus rapprochés.
Qu'en pensez-vous ?
Hors ligne
nicolas a écrit:
Je ne connais pas bien votre façon d'utiliser subversion. Pour ma part, j'essaie de ne pas commiter des trucs cassés pour ne pas géner les autres.
Je ne penses pas que ca soit délibéré mais plus des bugs... enfin, je penses...
AMA, tout le monde essaie de remonter des devs qui fonctionnent.
nicolas a écrit:
Ne pourrait-on pas prévoir la création de branches "personnelles" pour ce genre de chose qui permettraient de faire des commit plus rapprochés.
Qu'en pensez-vous ?
Je pense que ca risque de compliquer les choses.
Je pense qu'on se dépeche de commiter pour eviter de faire les merges avec les dev des autres et aussi pour montrer ce qu'on a fait.
Si on crée des branches personnelles, il faudra de toute façon faire le merge pour rependre les modifs (du style, fonction qui change de paramètre, ect...)...
Par contre, je me suis rendu que le merge auto et manuel de subversion est vraiment tres sympa.
Il suffit de faire un svn checkout pour avoir les dernières version, s'il peut merger, il merge tout seul, sinon en utilisant turtoise, tu peux faire un merge manuel en choississant ce que tu veux... c'est vraiment tres pratique...
Hors ligne
nicolas a écrit:
Je développe avec un niveau d'erreur maximal (2047 avec php4, 4095 avec php5) c'est-à-dire affichage de toutes les erreurs y compris avertissements (notice en grand breton) et sur certaines parties de code il y avait des notices notament avec l'utilisation de array_merge sur le script admin/site_update.php. Désolé je n'ai pas eu le temps d'investiguer plus profondément.
Je vais corriger ca. En php 4 il n'y avait pas d'erreur.
[EDIT]C'est fait. Ca marchait bien en php 4, mais pas du tout en php 5. Merci de me l'avoir signale.[/EDIT]
Dernière modification par rvelices (2006-03-28 05:11:17)
Hors ligne
(ça commence à être chaud... il est branche 1.6 moins 10 minutes et je n'ai toujours pas commité ma classification par tags, pourtant je suis à 95% du dev)
On peut décaller de 2 jours messieurs ? :-)
Hors ligne
euh... vu que je suis à 2 doigts de commiter les tags mais surtout qu'il me reste à retirer les liens source/destination avant de tirer la branche 1.6, l'opération est repoussée de 2 jours, donc RDV mardi soir. Désolé, profitez-en pour commiter ce qui vous reste :-)
Hors ligne
Tu te mets bien inutilement la pression à mon avis, mon ami.
Avec les problèmes de free, je me demande quelle qualité de retours nous aurons sur les tests des releases candidates.
Pour moi, le décalage de 2 ou 15 jours, ne changera rien. Free n'aura pas réglé son problème.
Et vu ce que renvoient les serveurs aux navigateurs, comme css ce n'est pas triste, c'est même très rigolo.
Je comprends que certains aient choisi de déménager.
8-)
Hors ligne
un petit coucou,
je pars en déplacement jusqu'au 12 au soir et si je pourrais faire une install de la 1.6, je ne pourrais la tester avant sérieusement.... mais ensuite, comptez sur moi !!
Hors ligne
Pas de soucis pour le décalage...
Hors ligne
Si on décale... Je dis bien si...
Il serait souhaitable que la procédure d'install suggère un upgrade si une table #_config existe déjà.
Hors ligne
z0rglub a écrit:
RDV mardi soir...
Que fait-on alors?
On attend le 12 avril pour la 1.6?
Hors ligne