Bonjour,
J'ai rajouté dans le spikini de SPIP Contrib le contenu des 3 fichiers
bugs.txt, nouveautes.txt et todo.txt.
- http://www.spip-contrib.net/spikini/BuGs
- http://www.spip-contrib.net/spikini/ToDo
- http://www.spip-contrib.net/spikini/HistoriqueNouveautes
Là encore, de manière à leur donner une visibilité plus grande.
Cordialement,
J'ai rajouté dans le spikini de SPIP Contrib le contenu des 3 fichiers
bugs.txt, nouveautes.txt et todo.txt.
- http://www.spip-contrib.net/spikini/BuGs
- http://www.spip-contrib.net/spikini/ToDo
- http://www.spip-contrib.net/spikini/HistoriqueNouveautesLà encore, de manière à leur donner une visibilité plus grande.
Un lien vers leur page sur le cvsweb serait plus judicieux, je pense,
car sinon les deux versions seront rapidement désynchronisées
-- Fil
J'ai rajouté dans le spikini de SPIP Contrib le contenu des 3 fichiers
bugs.txt, nouveautes.txt et todo.txt.
- http://www.spip-contrib.net/spikini/BuGs
- http://www.spip-contrib.net/spikini/ToDo
- http://www.spip-contrib.net/spikini/HistoriqueNouveautesLà encore, de manière à leur donner une visibilité plus grande.
Un lien vers leur page sur le cvsweb serait plus judicieux, je pense,
car sinon les deux versions seront rapidement désynchronisées
Il n'en faut qu'un c'est sur mais ou et sous quelle forme ?
pour le ToDo et les nouveauté, le wiki me semble le plus adapté.
Pour les bugs, un fichier dans un cvs c'est deja mieux mais il y a sans
doute encore mieux ...
Mais à la vitesse à laquelle bouge la cvs, j'ai un doute sur l'utilisation
effective d'une base de bug quelle que soit sa forme.
Les bugs sont généralement corrigés dès qu'ils sont identifiés et en
général, on se concentre sur les bug reproductibles (et donc quasiment
identifiés) sur une base de bugs.
Peut etre qu'une codification des objets des messages sur cette liste serait
moins contraignante et plus efficace (genre [BUG?], [BUG!] selon qu'il est
identifié ou non et/ou [BUG+] et [BUG-] pour signaler un bug et proposer un
correctif ...), qu'en pensez vous ?
>Un lien vers leur page sur le cvsweb serait plus judicieux, je pense,
>car sinon les deux versions seront rapidement désynchronisées
Il n'en faut qu'un c'est sur mais ou et sous quelle forme ?
pour le ToDo et les nouveauté, le wiki me semble le plus adapté.
Pour la TODO, certainement pas ! SInon ça va rapidement devenir un
répertoire de tous les [wishes] des spipeurs... Quant aux NOUVEAUTES,
j'ai déjà essayé de suggérer que ça serait pas mal si quelqu'un se
chargeait de les noter au fur et à mesure, mais personne n'a jamais
fait ce travail.
Peut etre qu'une codification des objets des messages sur cette liste serait
moins contraignante et plus efficace (genre [BUG?], [BUG!] selon qu'il est
identifié ou non et/ou [BUG+] et [BUG-] pour signaler un bug et proposer un
correctif ...), qu'en pensez vous ?
Je pense aussi qu'on a besoin de nouvelles règles du jeu pour
spip-dev, car la situation devient assez ingérable vu l'explosion de
"la demande".
On considère toujours qu'un mail décrivant un bug est, par définition,
une contribution importante, et on ne met pas de barrière à l'entrée
de ces mails-là. Pour un mail apportant un patch, aussi. Mais on a, en
plus, besoin de mails qui :
- confirment un bug en permettant de mieux le cerner
- signalent qu'un bug est déjà dans BUGS.txt (et modifient
éventuellement la desciption de ce bug)
- signalent qu'une demande est dans la TODO (et affinent)
- apportent un début de code à l'appui d'un mail déjà envoyé.
C'est ce travail-là que "la liste" pourrait faire. Ainsi, côté
core-développeurs, on aurait une manière de gérer des priorités, en se
concentrant sur les bugs confirmés et détaillés, et les patches
(complets ou non).
Sur le plan technique, quand vous voulez confirmer/préciser un
bug-report, il vaut mieux répondre au mail initial, de préférence sans
modifier le sujet ; ainsi dans nos gestionnaires de mail (j'uilise
maintenant Gmail) le threading se fait bien, et on peut travailler.
Donc pas besoin de mettre des descriptifs dans le sujet.
-- Fil
>Un lien vers leur page sur le cvsweb serait plus judicieux, je pense,
>car sinon les deux versions seront rapidement désynchronisées
Il n'en faut qu'un c'est sur mais ou et sous quelle forme ?
pour le ToDo et les nouveauté, le wiki me semble le plus adapté.
Pour la TODO, certainement pas ! SInon ça va rapidement devenir un
répertoire de tous les [wishes] des spipeurs... Quant aux NOUVEAUTES,
j'ai déjà essayé de suggérer que ça serait pas mal si quelqu'un se
chargeait de les noter au fur et à mesure, mais personne n'a jamais
fait ce travail.
Peut etre qu'une codification des objets des messages sur cette liste serait
moins contraignante et plus efficace (genre [BUG?], [BUG!] selon qu'il est
identifié ou non et/ou [BUG+] et [BUG-] pour signaler un bug et proposer un
correctif ...), qu'en pensez vous ?
Je pense aussi qu'on a besoin de nouvelles règles du jeu pour
spip-dev, car la situation devient assez ingérable vu l'explosion de
"la demande".
On considère toujours qu'un mail décrivant un bug est, par définition,
une contribution importante, et on ne met pas de barrière à l'entrée
de ces mails-là. Pour un mail apportant un patch, aussi. Mais on a, en
plus, besoin de mails qui :
- confirment un bug en permettant de mieux le cerner
- signalent qu'un bug est déjà dans BUGS.txt (et modifient
éventuellement la desciption de ce bug)
- signalent qu'une demande est dans la TODO (et affinent)
- apportent un début de code à l'appui d'un mail déjà envoyé.
C'est ce travail-là que "la liste" pourrait faire. Ainsi, côté
core-développeurs, on aurait une manière de gérer des priorités, en se
concentrant sur les bugs confirmés et détaillés, et les patches
(complets ou non).
Sur le plan technique, quand vous voulez confirmer/préciser un
bug-report, il vaut mieux répondre au mail initial, de préférence sans
modifier le sujet ; ainsi dans nos gestionnaires de mail (j'uilise
maintenant Gmail) le threading se fait bien, et on peut travailler.
Donc pas besoin de mettre des descriptifs dans le sujet.
-- Fil
(désolé si vous recevez ce mail 3 fois, j'ai l'impression que mes mails
depuis Gmail ne passent pas)
>Un lien vers leur page sur le cvsweb serait plus judicieux, je pense,
>car sinon les deux versions seront rapidement désynchronisées
Il n'en faut qu'un c'est sur mais ou et sous quelle forme ?
pour le ToDo et les nouveauté, le wiki me semble le plus adapté.
Pour la TODO, certainement pas ! SInon ça va rapidement devenir un
répertoire de tous les [wishes] des spipeurs... Quant aux NOUVEAUTES,
j'ai déjà essayé de suggérer que ça serait pas mal si quelqu'un se
chargeait de les noter au fur et à mesure, mais personne n'a jamais
fait ce travail.
Peut etre qu'une codification des objets des messages sur cette liste
serait moins contraignante et plus efficace (genre [BUG?], [BUG!] selon
qu'il est identifié ou non et/ou [BUG+] et [BUG-] pour signaler un bug et
proposer un correctif ...), qu'en pensez vous ?
Je pense aussi qu'on a besoin de nouvelles règles du jeu pour
spip-dev, car la situation devient assez ingérable vu l'explosion de
"la demande".
On considère toujours qu'un mail décrivant un bug est, par définition,
une contribution importante, et on ne met pas de barrière à l'entrée
de ces mails-là. Pour un mail apportant un patch, aussi. Mais on a, en
plus, besoin de mails qui :
- confirment un bug en permettant de mieux le cerner
- signalent qu'un bug est déjà dans BUGS.txt (et modifient
éventuellement la desciption de ce bug)
- signalent qu'une demande est dans la TODO (et affinent)
- apportent un début de code à l'appui d'un mail déjà envoyé.
C'est ce travail-là que "la liste" pourrait faire. Ainsi, côté
core-développeurs, on aurait une manière de gérer des priorités, en se
concentrant sur les bugs confirmés et détaillés, et les patches
(complets ou non).
Sur le plan technique, quand vous voulez confirmer/préciser un
bug-report, il vaut mieux répondre au mail initial, de préférence sans
modifier le sujet ; ainsi dans nos gestionnaires de mail (j'uilise
maintenant Gmail) le threading se fait bien, et on peut travailler.
Donc pas besoin de mettre des descriptifs dans le sujet.
-- Fil
spip-core est justement conçu pour ça.
ARNO*
Pour la TODO, certainement pas ! SInon ça va rapidement devenir un
répertoire de tous les [wishes] des spipeurs...
Salut !
ben justement ! J'ai point vu dans le todo le problème des balises <multi>
qui servent pour les objets "monolangues", comme les mots-clés. On a
toujours la problèmatique du tri quand on travaille avec ces mots-clés, le
tri se faisant sur la base de la langue par défaut.... On est ensuite obligé
de se torturer l'esprit (et demander de l'aide !) pour pouvoir trier ces
mot-clés dans les autres langues (plus de détail sur "vie du site" de
raforum.apinc.org)
Bon, à part cela, je ne suis pas exigeant ;-)))
JMB
Fil wrote:
J'ai rajouté dans le spikini de SPIP Contrib le contenu des 3
fichiers bugs.txt, nouveautes.txt et todo.txt.
- http://www.spip-contrib.net/spikini/BuGs
- http://www.spip-contrib.net/spikini/ToDo
- http://www.spip-contrib.net/spikini/HistoriqueNouveautesLà encore, de manière à leur donner une visibilité plus grande.
Un lien vers leur page sur le cvsweb serait plus judicieux, je pense,
car sinon les deux versions seront rapidement désynchronisées
Ok, j'ai remplacé par des liens sur le CVS.