g
o
o
g
l
e

mal codé aussi ?

Je pense encore une fois que tout le monde est reparti en vrille alors que ca redemmarrer plutot bien.
Alors respirer tous un grand coup et maintenant on revient sur les fondamentaux.

1) nous avons tous le desir de faire evoluer xoops par quelques moyens que ce soit(gigamaster avec xc, garrath avec ces contributions annexes a la teamdev, dugris dans la teamdev)

2) Il a un véritable problème de rancoeur mais loulous la !!!
Garrath, dugris vous etes tous les deux dans la même optique !!! Garrath se n est pas Gugris le team manager c DJ qui prend ka decision finale. Tu croit que dugris n a pas eu aussi ses idées et ces codes dev qui ont été envoyés à la poubelle?

3) Il faut aller de l avant et etre constructif. Giga tu nous rabaches les oreilles avec le passé mais quand est il des actions du futurs. Si on reste dans cet etat d esprit cela sera une impasse et je suis sur que tu n en doutes pas une seule seconde.

4) Oui y a eu de part et d autres des erreurs de managament dans le passé sur la team xoops. Mais cela est fait et maintenant il est impératif de se relancer. Arretons d avoir peur d'un deuxieme echec, nous sommes suffisament grand, le projet xoops a suffisament de rayonnance pour se relever.

Rappelez vous la question que j ai posé :
Xoops a besoin de personnes motivées a plusieurs niveau :
-Traducteur
-Developpeur
-Designeur
-Graphiste
-Documentaliste
-Manager
-betatesteur
-utilisateur lambda


On pourra alors créer une team qui aura pour seule but de pouvoir faire avancer xoops et cela sur tous les niveaux.

Nous en sommes la maintenant. La question n est pas de savoir si google est mal codé, la question n est pas de savoir qui est fautifs oui qui bosse.
La vrai question est allons nous de l avant en nous en donnant les moyens.

Qui est pret a bosser pour cette Team?

Citation :

je crois que tu en oublies une branche. je veux pas bosser pour ma paroisse mais force est de constater qu'une branche qu'on peut appeler comme on veux : marketing, communication... est manquante dans ce projet. ce post en est la preuve flagrante. ce sont les 2 axes majeurs a relever avec le developpement a mon avis. mais comme pour le dev, ce doit etre fait par des personnes ayant des connaissances dans le sujet. pas des potes de potes de potes.

Oui completement le pire c que j etais en train de te faire un mp pour ca

Surtout que pour ce qui est du marketing et du commercial un expert nous ferai du bien.

Tu en es?

je ne suis pas un expert, loin de là, mais disons que le sujet m'est plus proche que certains d'entre vous dans la communauté et surtout m'est encore plus proche qu'une ligne de code :p.

Pour ce qui est d'en être, je ne sais pas. j'avais proposé mes services aux plus hautes instances et j'attends leur besoin. j'avais fait un descriptif détaillé de certaines préconisations, je ne sais pas si elles ont été prises ou seront prise en compte. Je ne suis pas un masochiste comme certains d'entre vous qui s'acharnent. Je ne souhaite meme pas être mis en avant. Mais si je bosse pour rien et que les idées ne sont pas un minimum reprises (meme sans me citer, ca je m'en fout), ca me donne pas envie de continuer (démotivation : une des clefs du management), j'ai d'autres facons plus agréable de perde mon temps :-p. Donc wait and see

Citation :
Exactement... tout pareil

Citation :


Puisque tu as été gentil de répondre...

Il n'y a pas de contradiction !

Un apporte la serrure, un autre contribue avec le bois de la porte un autre avec une fenetre, un système d'alarme, etc.
Ceux qui ne peuvent pas contribuer, font des dons et La Fondation....Oops, n'a jamais participé aux travaux!
Bref, t'as aussi l'exemple du "Repas Canadien",
tu invites tes potes mais chacun apporte son souper.
Je pense qu'ils appellent ça... du savoir vivre, tradition

Tu vois toujours une contradiction?

Peut être qu'il y avait du bois aussi,
mais personne pour faire la porte ni
fixer les fenêtres...

Hummm... si les erreurs du passé ne sont pas comprises
elles risquent de se reproduire une fois encore sur Xoops2.


En 2005, la discussion dans les forums anglais de xoops.jp sur l'avenir des sites sous Xoops 2 avaient pour objectif trouver un moyen de sortir de l'impasse.

Il fallait des programmeurs compétents et une stratégie claire pour ne pas recommencer les mêmes erreurs et pouvoir évoluer.

Minahito, un programmeur professionnel a présenté une solution pour gèrer le code légué et assurer une compatibilité sur une base solide. Mais aussi un concept de développement inspiré de l'univers du développement du jeux (core minimaliste, modulaire et extensible). Nobunobu le core cube et 'web services', avec Tom l'interface utilisateur et système de rendu. Ce qui devrait permettrait à chacun d'être créatif et d'innover indépendamment du system (xoops, joomla, drupal, etc).

Une fois tout le monde d'accord sur la philosophie open source et la direction du projet nous avons commencé ce qui est aujourd'hui - XOOPS Cube Legacy !

Nous avons eu une importante modification en cours de route.
Les modules de Base sont devenus des modules Legacy sous licence GPL tout comme Xoops et le code de Cube a gardé la licence BSD.

Les discussions entre les deux équipes ont eu souvent comme sujet "Reduce the Gap" mais si rien n'a été fait pour assurer la compatibilité sur xoops.org, c'est pas faute d'avoir voulu aider. C'est peut être qu'il n'y a personne avec les compétences pour le faire.

Le framework CSS/Design est en cours de traduction, mais je manque de temps, on chasse, en réseau, les méchants sur Halo3!


Le mieux, c'est de vous faire votre propre opinion, et du code, et de l'ergonomie de XOOPS Cube Legacy.


En attendant que Marco publie les différences et avancés technologiques du projet dans une comparaison avec Xoops 2.

J'ai DL legacy et j'ai rapidement regarde le code de 2 3 trucs... c'est juste mes premieres impressions et premieres questions.

D'abord, c'est pas vraiment un truc leger ca pese dans les 7 Mo contrairement a xoops qui est au dessous des 2 Mo (c pas une critique mais une constatation).
Ensuite legacy a son propre core et a en plus le kernel de xoops (donc on enleve les 2Mo de xoops reste quand meme 5 mo) . Il n'emule donc pas le fonctionnement de xoops pour utiliser des modules de xoops il a entierement le code xoops (donc ces bons cotes comme les mauvais)

Par contre, le code du core de legacy fait bien plus penser a de l'objet que celui de xoops
Ca c clair. Bon du php4 mais on sent deja que c concu objet.

On voit aussi que l'on utilise un controleur pour les pages ce qui fait que la page index.php d'un module est super reduite

Certaines des critiques que j'ai pu faire par exemple sur les fichiers a la racine de xoops ont l'air d'etre corrige - typiquement pour donner un exemple Viewpmsg.php son code n'est pas la, la on a juste une redirection et un appel... ce qui fait que a priori si on cree une gestion particuliere des mp on doit pas avoir besoin de modifier ce fichier contrairement a xoops...

Il a pas l'air prevu non plus pour fonctionner avec d'autres bdd que Mysql (en meme temps il reprend le noyau actuel de xoops)

Bon forcement j'ai regarde rapidement les trucs qui me chiffonnent sour xoops je suis pas rentre plus dans les details...

Ce qui me chiffonent quand meme c'est pourquoi il embarque quand meme le kernel de xoops? et cela sans l'avoir corrige
Apres ce qu'il vaut en terme de perfs? car a un moment donne il doit quand meme switcher de core pour 'emuler' un fonctionnement xoops non?

Citation :

Très simple à comprendre pourtant, pour profiter de la multitude de module Xoops existant. Sinon il n'y aurait en effet aucun insert à conserver le core de Xoops.