[spip-dev] Faire le point avec une version stable?

Dev
1

Bonjour !

Le code de Spip continue à évoluer vite. De temps à autre il y a des vrais
avantages, il me semble, à faire un pause dans l'introduction de nouveautés,
pour consolider les acquis.

Par exemple: cela fait un certain temps que des avancées dans la syntaxe des
boucles (#nom_de_boucle:BALISE, utilisation de balises dans les critères
d'une boucle) sont présentes dans 1.8 CVS. Ce sont des avancées qui
simplifient grandement l'écriture de squelettes. Pensons-nous à les offrir à
la communauté Spip plus large?

C'est n'est pas que je veux freiner. Mais si une distance trop grande
s'ouvre entre la liste développeur et la base d'utilisateurs Spip, cela
serait dommage, et aurait à terme des effets négatifs aussi sur le
développement.

Paolo

2

Nous en sommes bien conscients, et nous discutons en ce moment entre nous de ce qui nous parait devoir figurer dans la nouvelle version ou pas. Une nouvelle version donne une certaine image de Spip, il faut veiller à sa cohérence interne d'une part,
et sa cohérence avec son avenir. Par exemple, j'arrive déjà à faire tourner plusieurs espaces publics avec un meme source Spip,
mais j'ai encore des pbs avec l'espace privé (à cause des redirections). Me donner le temps d'aller jusqu'au bout, c'est retarder la sortie de la nouvelle version, mais d'un autre côté ne pas le faire risque d'inciter à des contributions qui seront irrécupérables dans un avenir proche. De même, l'utilisation à terme du compilateur pour l'espace privé amènera surement des
révisions sur son architecture, et donc invalidera la possibilité actuelle de redéfinir certaines de ces parties.

Je pense que la meilleure chose que puissent faire les abonnés de cette liste, c'est de lister ce qui leur parait incohérent
dans la CVS actuelle: ca permettra de voir ce qui est complétable et documentable rapidement,
et ce qui ne sera documenté que dans une version ultérieure si la complétude est trop lointaine.

      Emmanuel

3

En clair, ne serait-il pas judicieux d'erréter une 1.8.0 avant
d'officialiser des plugin et autres champs extra ?
  Ça me parait effectivement pertinent.

À+, Pif.

4

Le code de Spip continue à évoluer vite. De temps à autre il y a des

vrais

avantages, il me semble, à faire un pause dans l'introduction de

nouveautés,

pour consolider les acquis.

En clair, ne serait-il pas judicieux d'erréter une 1.8.0 avant
d'officialiser des plugin et autres champs extra ?
Ça me parait effectivement pertinent.

Si ce que tu appelles "champs extra" fait references à la possibilité
d'adresser d'autres champs et tables, c'est un peu tard, et dans la mesure
ou ca ne change ni la syntaxe, ni la facon de créer des filtres, ca ne pose
pas vraiment de problemes à mon avis.
Pour le systeme de plugin, c'est plus delicat.
Il faudrait au moins arreter les mecanismes généraux (API en particulier)
avant la sortie de la 1.8.
la fonctionnalité peut etre peu ou pas implementée mais la structure elle
doit etre suffisement aboutie pour ne pas bloquer les developpements autour
de Spip.
Idem pour l'approche multibase, multispip ...
Si des parametres supplementaires sont necessaires, ils doivent etre ajoutés
tout de suite aux fonctions, meme si on ne fournit pas aujourd'hui le code
les utilisants.

Disons d'une maniere generale que la 1.8 doit, amha, etre pensée pour etre
le plus compatible possible avec la "1.9CVS" (qui va peut etre finir par
etre une 2.0 non ? ou il y a un objectif fonctionnel particulier pour passer
en v2 ?)

Mes 2 cents ...

5

Paolo wrote:

Le code de Spip continue à évoluer vite. De temps à autre il y a des vrais avantages, il me semble, à faire un pause dans l'introduction de nouveautés, pour consolider les acquis.

Faudrait faire le point sur les performances aussi.

Détecter et éradiquer les éventuelles dégradations,
genre tendance à exploser en time-out.
(j'ai quelqu'inquiétude qui ne demandent qu'à être calmées)

JLuc

6

Disons d'une maniere generale que la 1.8 doit, amha, etre pensée pour etre
le plus compatible possible avec la "1.9CVS" (qui va peut etre finir par
etre une 2.0 non ? ou il y a un objectif fonctionnel particulier pour passer
en v2 ?)

une version 2, ça voudrais réecriture d'une grosse partie du code, changement dans les fondations, organisations rationalisés et gros chantier de ce genre.
Je pense plutot qu'il y aura une 1.10 aprés la 1.9

M.

7

Est-il possible d'avoir une liste (la plus exhaustive possible) de tout ce qui a été fait afin de pouvoir sélectionner ce qui nous parait cohérent de mettre dans une 1.8 ?

Merci

A+

Déesse A. a écrit :

8

>> Le code de Spip continue à évoluer vite. De temps à autre il y a des
vrais
>> avantages, il me semble, à faire un pause dans l'introduction de
nouveautés,
>> pour consolider les acquis.
> En clair, ne serait-il pas judicieux d'erréter une 1.8.0 avant
>d'officialiser des plugin et autres champs extra ?
> Ça me parait effectivement pertinent.
Si ce que tu appelles "champs extra" fait references à la possibilité
d'adresser d'autres champs et tables, c'est un peu tard, et dans la mesure
ou ca ne change ni la syntaxe, ni la facon de créer des filtres, ca ne pose
pas vraiment de problemes à mon avis.

  Non, je parle des "vieux" champs extra, qui sont toujours à un statut
"non supporté" et dont il faudrait décider s'ils le restent ou pas.

Pour le systeme de plugin, c'est plus delicat.
Il faudrait au moins arreter les mecanismes généraux (API en particulier)
avant la sortie de la 1.8.

  Et pourquoi ne pas rester là ou ils sont et les mettre également au
statut "non supporté" pour l'instant.
  Ça évite de dégager ce qui est déjà écrit, sans obliger à rester
compatible à l'avenir.

la fonctionnalité peut etre peu ou pas implementée mais la structure elle
doit etre suffisement aboutie pour ne pas bloquer les developpements autour
de Spip.

Idem pour l'approche multibase, multispip ...
Si des parametres supplementaires sont necessaires, ils doivent etre ajoutés
tout de suite aux fonctions, meme si on ne fournit pas aujourd'hui le code
les utilisants.

  C'est le meilleur moyen de faire à la va vite est d'être emmerdés plus
tard pour rentrer dans le moule.

  De toutes façons, tout ça, c'est des fonctions avancées.
  Pourquoi ne pas faire une 1.8 qui contient
- le nouveau compilo et la possibilité d'ajouter des colonnes et tables
- la nouvelle interface graphique
- toutes les nouveautés "grand public" apparues entre temps.

  En clair, la 1.8rc1 + bugfixes

  À coté, les autres chantiers (extras, colonnes supplémentaires coté admin,
plug ins, multi bases) reste à l'état de "en travaux", et donc "utilisable
à vos risques et périls".

À+, Pif.

9

Salut,

Si on discute de ce qu'il faut mettre dans une version 1.8 officielle, une des choses à faire est sans doute d'examiner les développements du lab qui peuvent être récupérés.

En particulier, il a deux gros patchs très intéressants écrits par Antoine qui sont disponibles:

- le système de notification
  http://lab.spip.net/spikini/SystemeDeNotifications

- le système de gestion de formulaires
  http://lab.spip.net/spikini/CreationDeFormulairesPublics

Dans les deux cas, il s'agit de nouveautés importantes (et donc sans doute pas encore prêtes à être intégrée dans une 1.8 à très court terme). Mais ça vaudrait peut-être la peine de commencer à les tester intensivement en vue d'une intégration pas trop lointaine.

Dans le même genre, il y a la grosse contrib d'Alexandre (http://www.linagora.org/article90.html) pour la gestion de groupes de mots-clés en arborescence dont l'intégration mérite à mon avis aussi d'être envisagée.

bonne journée à tous,

François

10

Est-il possible d'avoir une liste (la plus exhaustive possible) de tout ce qui a été fait afin de pouvoir sélectionner ce qui nous parait cohérent de mettre dans une 1.8 ?

et tous les messages suivants.

      Emmanuel

11

je parle des "vieux" champs extra, qui sont toujours à un statut
"non supporté" et dont il faudrait décider s'ils le restent ou pas.

en tout cas, moi je ne les supporte pas :wink:

Pour le systeme de plugin, c'est plus delicat.

Idem pour l'approche multibase, multispip ...
Si des parametres supplementaires sont necessaires, ils doivent etre ajoutés
tout de suite aux fonctions, meme si on ne fournit pas aujourd'hui le code
les utilisants.

  C'est le meilleur moyen de faire à la va vite est d'être emmerdés plus
tard pour rentrer dans le moule.

C'est aussi mon avis: finaliser ou laisser sans rien officilaliser.

  De toutes façons, tout ça, c'est des fonctions avancées.
  Pourquoi ne pas faire une 1.8 qui contient
- le nouveau compilo et la possibilité d'ajouter des colonnes et tables
- la nouvelle interface graphique
- toutes les nouveautés "grand public" apparues entre temps.

oui, mais il faut s'entendre sur "nouveau compilo":
les champs des boucles externes, les variables d'URL,
bref tout ce qui se voit dans un squelette ok.
Mais l'API PHP du compilo, ça me parait prématuré:
on ne sait pas comment ça va évoluer. Restera-t-il meme en PHP à terme ?

Ce sur quoi on peut/doit s'engager, ce sont les squelettes, donc les champs et les filtres.
A bien y regarder, l'introduction de nouvelles balises peut se simuler avec des filtres.
Pas toujours proprement certes, mais ça ménage l'avenir.

      Emmanuel

12

Déesse A. a écrit :

je parle des "vieux" champs extra, qui sont toujours à un statut
"non supporté" et dont il faudrait décider s'ils le restent ou pas.

en tout cas, moi je ne les supporte pas :wink:

Est-ce qu'il y a tant de choses à maintenir pour les champs extra?

Il faut intégrer la dernière librairie (permettant de gérer d'autres types de champs que des input text et des textarea (select,..)) qui est, je pense, disponible et fonctionnelle.

Le seul élément sensible, me semble-t-il, c'est de savoir (et de dire dès à présent aux webmestres qui s'engageront dans l'utilisation de champs extra) s'il sera possible, le moment venu, de fournir un outil permettant le transfert du contenu des champs extra vers le nouveau système.

François

13

oui, mais il faut s'entendre sur "nouveau compilo":
les champs des boucles externes, les variables d'URL,
bref tout ce qui se voit dans un squelette ok.
Mais l'API PHP du compilo, ça me parait prématuré:
on ne sait pas comment ça va évoluer. Restera-t-il meme en PHP à terme ?

Désolé, mais là, moi, je ne vous suis plus... c'est là où je mesure mon degré de compétences...
C'est quoi la différence ?
Et puis on l'utilise déjà l'API php du nouveau compilo sur les version en cours non ?

Merci et désolé pour ces questions simplistes, mais j'ai des doutes...

A+

14

François Schreuer a écrit :

Déesse A. a écrit :

je parle des "vieux" champs extra, qui sont toujours à un statut
"non supporté" et dont il faudrait décider s'ils le restent ou pas.

en tout cas, moi je ne les supporte pas :wink:

AMHA : Laissez tomber les champs extras, c'est bien pour les bidouilles, mais pas pour Spip: en revanche il faut stabiliser le compilo et son interface.

Est-ce qu'il y a tant de choses à maintenir pour les champs extra?

Il faut intégrer la dernière librairie (permettant de gérer d'autres types de champs que des input text et des textarea (select,..)) qui est, je pense, disponible et fonctionnelle.

As tu mis à jour le wikki à ce sujet ?

Le seul élément sensible, me semble-t-il, c'est de savoir (et de dire dès à présent aux webmestres qui s'engageront dans l'utilisation de champs extra) s'il sera possible, le moment venu, de fournir un outil permettant le transfert du contenu des champs extra vers le nouveau système.

Ca fera une bonne contrib quand le compilo sera stable et documenté.

Plus largement, je suis assez d'accord sur le fait qu'il faudrait ralentir l'intégration de nouveau code, de stabiliser ce qui existe, et de le documenter.

Car il faut laisser du temps pour mettre à jour les sites, les squelettes, les contribs etc...

BoOz

15

BoOz a écrit :

AMHA : Laissez tomber les champs extras, c'est bien pour les bidouilles, mais pas pour Spip: en revanche il faut stabiliser le compilo et son interface.

Je suis d'accord, mais ce n'est valable qu'à long terme. Parce que, d'ici là (la 1.9, la 1.10, la 2.0 ?), il n'existe pas de système permettant de faire ce que les champs extra font aujourd'hui. C'est le noeud du problème.

La question n'est pas de péréniser les champs extra dans spip ad vitam aeternam (et, oui, les webmestres savent qu'ils utilisent un outil "à la marge" et que ça implique des risques pour eux), mais de garantir la continuité fonctionnelle en ne retirant pas su service les champs extra tant qu'ils sont encore utiles.

Et, tant qu'à faire, durant l'intervalle (qui durera peut-être encore un an ou deux), autant intégrer les développements qui ont été faits sur les champs extra: ils existent et ils seront utiles.

Amicalement,

François

16

BoOz wrote:

François Schreuer a écrit :

Déesse A. a écrit :

je parle des "vieux" champs extra, qui sont toujours à un statut
"non supporté" et dont il faudrait décider s'ils le restent ou pas.
       

en tout cas, moi je ne les supporte pas :wink:
     
AMHA : Laissez tomber les champs extras, c'est bien pour les bidouilles, mais pas pour Spip: en revanche il faut stabiliser le compilo et son interface.

Est-ce qu'il y a tant de choses à maintenir pour les champs extra?

Il faut intégrer la dernière librairie (permettant de gérer d'autres types de champs que des input text et des textarea (select,..)) qui est, je pense, disponible et fonctionnelle.
   
As tu mis à jour le wikki à ce sujet ?

Le seul élément sensible, me semble-t-il, c'est de savoir (et de dire dès à présent aux webmestres qui s'engageront dans l'utilisation de champs extra) s'il sera possible, le moment venu, de fournir un outil permettant le transfert du contenu des champs extra vers le nouveau système.
   
Ca fera une bonne contrib quand le compilo sera stable et documenté.

Plus largement, je suis assez d'accord sur le fait qu'il faudrait ralentir l'intégration de nouveau code, de stabiliser ce qui existe,

Test unitaire, optimisation et tout ça?

et de le documenter.

avec phpdocumentor?

Car il faut laisser du temps pour mettre à jour les sites, les squelettes, les contribs etc...

Et le nettoyage, les fonctions oubliés, les .php3 en .php, les gros bouts de HTML sans CSS, les jolis dossier comme dans le lab?

M.

17

François Schreuer a écrit :

BoOz a écrit :

AMHA : Laissez tomber les champs extras, c'est bien pour les bidouilles, mais pas pour Spip: en revanche il faut stabiliser le compilo et son interface.

Je suis d'accord, mais ce n'est valable qu'à long terme. Parce que, d'ici là (la 1.9, la 1.10, la 2.0 ?), il n'existe pas de système permettant de faire ce que les champs extra font aujourd'hui. C'est le noeud du problème.

Ah bon ?
Que manque t'il ?

N'y a t'il pas deux contrib d'Emmanuel ?

1) le compilo
2) l'interface pour la partie privée ?

Peux tu me préciser tout ca car je suis ca de loin pour le moment.

18

il est vrai que, du point de vue d'un webmaster de base, ces fonctions seraient des plus values immediatement utilisables (avec versionning, correcteurs, nouvelle interface admin, etc...) ... et directement utiles aux rédacteurs aussi d'ailleurs .. je pense que le systeme de notification évolué par exemple, permettrait d'aboutir le fonctionnement des forums spip

Les bénéfices du nouveau compilo apparaissant à plus long terme à travers les contribs et autres fonctions de programmation de squelette qu'il permet .. il faut plus de compétence et de temps pour apprécier

@+
Nicolas RIQUOIS
http://www.pucroller.com

19

effectivement mais l'interface pour la partie privé ne gere pas en l'etat les champs rajouté au tables originelles et il n'y a aucune gestion des droits dessus, cela ne peut pas en l'etat remplacer les champs extra.

Pour moi c'est la seul fonction qui manque pour sortir une 1.8 avec peut etre le système de notification issu du lab

20

François Schreuer wrote:

Salut,

Si on discute de ce qu'il faut mettre dans une version 1.8 officielle,
une des choses à faire est sans doute d'examiner les développements du
lab qui peuvent être récupérés.

En particulier, il a deux gros patchs très intéressants écrits par
Antoine qui sont disponibles:
...
Dans les deux cas, il s'agit de nouveautés importantes (et donc sans
doute pas encore prêtes à être intégrée dans une 1.8 à très court
terme). Mais ça vaudrait peut-être la peine de commencer à les tester
intensivement en vue d'une intégration pas trop lointaine.

Je dirais même qu'il me paraitrait souhaitable de les intégrer dans le core,
peut-être seulement activables par une variable dans mes_options.php3 pour
en disposer tout de suite officieusement.

Dans le même genre, il y a la grosse contrib d'Alexandre
(http://www.linagora.org/article90.html) pour la gestion de groupes de
mots-clés en arborescence dont l'intégration mérite à mon avis aussi
d'être envisagée.

Pareil !