nicolas a écrit:

Cela va faire près de 15 jours qu'on a fait la RC1 et la RC2 n'est pas encore sortie.

J'aurais aimé la sortir plus tôt mais là j'ai perdu du temps sur des tracas administratifs + je suis pas d'une forme olympique depuis 3 jours ("en avril ne te découvre pas d'un fil", j'ai juste oublié).

Comme je disais à ddtddt ce soir, je fais du debug sur UploadForm en ce moment, et notamment impossible de faire marcher le formulaire à sélection multiple sur le serveur piwigo.org, pour moi, je suis vraiment en "phase de debug" (surtout après le sermon de nicolas ;-)

rub a écrit:

rub a écrit:

Mais je préfère en objet car ça ouvre plus de possibilité.

De plus, il n'avait pas été dit que nous ferions de plus en plus d'objet?

Je découvre cette discussion. je ne recite pas tous les échanges mais pour ma part, plus il y a de programmation objet, mieux c'est.

Et je n'ai pas attendu le débat :
- tous mes plugins exploitent des classes communes (dans GrumPluginClasses, il y a "classes" ;-)) qui leurs offrent des fonctionnalités de base sur l'intégration dans Piwigo
- suite à la nouveauté offerte de disposer d'une interface pour les thèmes, j'ai créé une classes pour les miens (j'ai hésité à exploiter GrumPluginClasse, mais je me suis dit que çà pouvait être compliqué d'imposer çà juste pour un thème)


Avantages :
- quand une classe évolue, tous les composants exploitant la classe bénéficient de l'évolution
- possibilité de surcharger une classe (très pratique)
- pour créer un plugin avec un interface, une procédure d'installation avec gestion de la config, je n'ai quasiment rien à coder car c'est déjà fait

Après, mes classes sont perfectibles (dans l'implémentation et l'usage) et leur modèle n'est peut-être pas le bon. Mais pour ma part, elles me conviennent parfaitement.

par contre, ce topic est-il vraiment le bon endroit pour causer de tout çà ???

nicolas a écrit:

Pour ma part, et je l'ai signalé à Pierrick qui en a convenu (même si sa position s'est asouplie par rapport à il y a quelques années; peut-être le début de la sagesse!!!), la phase de Release Candidate ne doit apporter aucune nouvelle fonctionnalité. On ne fait que stabiliser du code, corriger des bugs. Là clairement ce n'est plus de la stabilisation mais des évolutions. Le fait qu'on soit en RC1 ou RC2 ou RCn ne change rien au processus.

Après il faut peut-être revoir cela et créer une nouvelle branche juste avant la première RC. Sinon on fait durer la phase de RC pendant des semaines. SI on tire la branche dès le départ et qu'on est dès le départ en correction de bugs, corrections des premiers problèmes rencontrés et stabilsation du code, le processus est plus court. Personnellement je n'aime pas trop cette phase, autant la rendre la plus courte possible. Cela va faire près de 15 jours qu'on a fait la RC1 et la RC2 n'est pas encore sortie.

Je suis tout à fait d'accord avec toi.

nicolas a écrit:

qu'on soit en RC1 ou RC2 ou RCn ne change rien au processus.

Je faisais la comparaison RC1 & RC2 uniquement par rapport à ceux qui a été fait actuellement pas comme un processus générique.

nicolas a écrit:

p.s: Ce n'est peut-être pas la bonne discussion pour en parler mais c'est toi qui a commencé, enfin peut-être pas finalement mais tant pis.

C'est vrai mais je ferme juste la parenthèse.

nicolas a écrit:

plg a écrit:

nicolas a écrit:

Cela va faire près de 15 jours qu'on a fait la RC1 et la RC2 n'est pas encore sortie.

J'aurais aimé la sortir plus tôt mais là j'ai perdu du temps sur des tracas administratifs + je suis pas d'une forme olympique depuis 3 jours ("en avril ne te découvre pas d'un fil", j'ai juste oublié).

C'était juste pour tenter de freiner un p'tit rub dans son élan.

Je prends le train en route... tant qu'à ajouter des trucs, vu ce qui se passe dans la RC1, autant le faire de suite.
Pour moi, la RC1 n'est pas une vrai RC compte-tenu des évolutions ajoutées et aussi parce que la partie upgrade n'est pas finalisée voir faite... C'est comment dire, plus une béta ou une alpha...

Mais sans pour autant être un RC, la RC1 a été un super booster pour les devs... => avant les RC, ne serait-il pas bon de faire des versions alpha version de pré-release?

Promis, on continuera la discussion sur un autre topic ;-)

P@t a écrit:

Je répète qu'un créateur de thème n'est pas forcément callé en php: je me revois deux ans en arrière à mes début en programmation, je ne comprenais scritement rien au classes, et quand j'en voyais une, je préférais passer mon chemin... les choses ont changées bien sur, mais ne repoussons pas les développeurs de thèmes avec des choses compliquées et inutiles. Je rapelle qu'un des objectifs de ce nouveau système de thèmes/templates est d'augmenter le nombre de contributions!

Pour moi, l'installation de Piwigo ne devrait activer que les thèmes de base (clear, dark et Sylvia) pour éviter toutes sortes de problème (dont celui-ci!)

Je suis en accord avec cela

Dès que l'on parle chiffon, je vois que ça part vite en liveeee. Merci du pourrissage de post (nan, je déconne).
C'est vrai qu'il parrait logique, maintenant qu'il y a un gestionnaire de plug in, d'avoir un gestionnaire de theme.
Comme dit plus haut, il faut alléger les procédure de fabrication du visuel pour avoir suffisamment de theme en banque pour avoir le choix dans le gestionnaire, sinon à quoi servirait un tel outils si rien n'est proposé à télécharger. D'ailleur, y a-t-il un working group pour les visuels?

Gotcha a écrit:

arn_bwkrd a écrit:

D'ailleur, y a-t-il un working group pour les visuels?

Je pense que ce sera fait à la suite de la sortie de la 2.1

Working group = groupe de travail, si je ne m'abuse ...

arn_bwkrd a écrit:

Dès que l'on parle chiffon, je vois que ça part vite en liveeee. Merci du pourrissage de post (nan, je déconne).

Je propose de continuer la discussion dans un lieu plus approprié : http://fr.piwigo.org/forum/viewtopic.php?pid=139918