C’est de mon point de vue le point le plus important.
Probablement déjà le cas.
Jeedom à un historique et dérive. L’approche de la v4 était majoritairement graphique. La question ne serait-elle pas une revue complète du core pour une v5. Identifier tous les éléments qui posent des soucis qui pénalisent la maintenance, les évolutions et le développement de plugins au quotidien.
C’est hors sujet de ce post, et il faudrait plutôt un sujet ouvert à l’échange et à l’écoute. Il faut arrêter de prendre mal la critique (la critique est un examen raisonné, objectif, qui s’attache à relever les qualités et les défauts et donne lieu à un jugement de valeur).
Si quelqu’un se pense éligible à initier ce type d’examen des points d’amélioration, qu’il se lance. Si cela pouvait venir de la team Jeedom cela serait un gage d’ouverture d’esprit.
Cette démarche serait bénéfique au devenir de Jeedom et surtout permettrait probablement de reprendre la main, car aujourd’hui Jeedom stagne voir régresse sur certaines fonctionnalités qui disparaissent, car trop compliqué à maintenir. Une revue du core devrait permettre un meilleur maintien et faciliter le travail de tous.
Je parlais d’éventuels mercenaires sur le core.
Pour moi y’a pas vraiment de soucis la dessus côté équipe Jeedom. D’où aussi ce que j’explique me concernant, étant mercenaire et pas jeedom.
Pour le reste, je pense en effet que c’est à jeedom d’ouvrir le débat et de porter une telle volonté si c’est le cas.
Pour ce qui est des PR et de codes non maintenu sincèrement on a taper partout sur le v4 et 4.1. Il n’y a à mon sens pas de zones d’ombre ou non maîtrisées côté code. D’où certains freins sur certaines directions pour ne justement pas perdre cette maîtrise.
On n’est un peu hors sujet en effet mais ça reste une discussion intéressant
Sur cette partie là, je suis pas tout à faire en accord :
Il y a plein des blocs entiers de copié/collé qui mériterai d’être passer sous forme de fonctions. ça rendrai aussi la maintenance vachement plus simple, et n’aurai pas besoin de porter N corrections à chaque bug.
ça rendrait les chose aussi plus uniformes, par exemple : il a y des fonctionnements étranges notamment dans tout ce qui est analyseur syntaxique… Ne pas avoir le même résultat dans le testeur et dans un scénario, c’est ni logique ni sain, mais comme le code n’est pas le même…
Et pour rendre le code accessible à plus grande échelle, il n’y a pas de solution miracle : des commentaires, des changelogs, des infos sur les évolutions/changements
Et je rejoins la remarque de @sbo quant à la stagnation/regression… La solution de simplicité en supprimant la fonctionnalité parce qu’elle bugge, c’est trop court-termiste et pas viable
Tout ça, c’est évidement plus simple à dire qu’à faire mais si c’est pas une réelle volonté de l’équipe Jeedom, toutes les bonnes volontés n’iront pas bien loin. Et personnellement je ne suis malheureusement pas très optimiste
Intéressant en effet, je vais jeter un œil et voir ce qu’on peut factoriser, merci
Si vous voyez d’autres points d’amélioration faut pas hésiter.
A voir avec @Alexandre si on peux avoir un sous forum style: Salon des Développeurs → Contributions Core
Accessible que pour certaines personnes prêtes à donner un peu de leur temps sur ce sujet ?
On pourrait créer des sujets sur des mini-chantiers comme celui-là avec ceux qui souhaitent participer, et en discuter avant de proposer des PRs, que tout le monde soit raccord. Ce qui évite de découvrir un PR tombé de nulle part ?
@Alexandre@Loic vous en penser quoi ? Je veux bien essayer de suivre là dessus, si çà se passe dans la bonne humeur et de manière constructive bien sûr.
Je tiens à préciser qu’on fera pas grand chose je pense sur la 4.1. Elle est en fait stable, mais attend que la 4.0 passe officiellement en stable pour ensuite passer la 4.1 en beta. Mais pour la prochaine alpha 4.2 on peux déjà référencer plusieurs sujets. Si l’équipe Jeedom est ok bien sûr, je suis en mode mercenaire là
@David ? Je veux pas non plus pousser quelque chose si ce n’est pas souhaité par Jeedom
Pour ma part ayant le core ouvert en permanence quasi pour soit vérifier des questions que je vois passer sur le forum soit vérifier ce que je peux faire dans mes plugins, je commence à bien le connaître et avoir explorer énormément dessus.
Et vu que j’ai ne fut ce que un linter actif, je relève assez régulièrement des variables qui n’existent pas (qui vont créer des bugs donc) ou juste plus utilisées (moins grave mais ça n’aide pas à la lisibilité) et parfois quelques points plus importants
Je serai content de pouvoir faire des PRs pour ca (pareil sur certain plugin officiel d’ailleurs) mais il faut plus d’interactions, que les PRs soient suivis relativement rapidement aussi: le problème quand c’est vérifié quelques semaines/mois plus tard c’est que le merge auto est plus forcément possible car la base a trop changée, du coup PR rejeté, on refait nos merges et hop nouveau PR reparti pour quelques semaines… c’est pas gérable en tant que contributeurs
Pour les plugins je ne m’en occupe pas du tout donc je ne réagirai pas.
Mais ce que tu décris sur le core, je suis d’accord et trouve dommage qu’on n’en profite pas. Retour à mon post précédent avec un forum dédié pour en parler et quand le pr arrive on a qu’à merger car on en a déjà parlé. À voir donc si l’équipe est ok sur une telle faisa. On a pas besoin d’être 40 non plus mais une fine équipe d’initiés ce serait quand même top pour tout le monde, y compris pour Loïc qui est très chargé entre core/plugins/doc/infra etc.
Qui serait intéressé, et compétent bien sur, pour corriger, debugger, améliorer le Core de Jeedom ?
En précisant si vous êtes déjà à l’aise avec le code du Core, plutôt php, js, front, back etc ?
Le but ne serait pas de partir dans tous les sens chacun dans son coin, mais au contraire de discuter ensemble de points précis pour y répondre au mieux, dans l’intérêt de jeedom et de ses utilisateurs
Je suis prêt a debugger et améliorer le Core.
Je connais un peux le core. (Surtout pour dev mes plugin)
Cotée PHP, je ne saurais évaluer mon niveaux. (Appris sur le tat au fur et a mesure de mes envie)
Cotée JS, c’est la même chose.
Cotée Front, je peux faire, mais je suis moins fan
Cotée Backend, Je suis beaucoup plus fan
Je rajoute 2 point qui ne sont pas inutile :
Coté Core, j’ai pas mal compulsé le code, donc je suis pas perdu. Je veux bien apporter mon aide pour tester tout ça (j’ai de toute façon l’alpha qui tourne en prod depuis quasiment le début). Je n’aurai pas forcement de plus-value sur la partie JS (CSS, etc ça me branche moyen) mais je peux sans doute apporter quelques idées autant coté front, que back
Détail important tout de même, les beta-testeurs n’ont pas accès à la partie dev du forum
Hello.
Malheureusement j’ai bien l’impression que l’idée est morte née : pas de réaction des différents nommés (même négative) et pas de nouvelle catégorie (du moins chez moi)… Cumulé avec un certain nombre de choix (rester sur openzwave v1.4) ou les évolutions qui tardent par rapport à la roadmap, ça conforte malheureusement un sentiment naissant chez moi, d’un futur moins radieux pour jeedom.
Bon il faut s’incliner, il ne semble pas que résoudre certains problèmes de fond ou apporter des améliorations sur une future version soit dans les tablettes de la Team Jeedom.
C’est dommage et je comprends mieux l’intérêt de certains à préparer une transition.
Une petite pensée à tous ceux qui ont proposé une aide et qui n’ont même pas eu le moindre signe d’intérêt.
Je comprends ton point de vue mais il faut aussi se mettre du point de vue de l’équipe jeedom.
Si je prends le système de helper qui a été mis en place il y a qqs mois. On était beaucoup au début et maintenant plus que 17 et ds ces 17, il y a déjà une petite dizaine d’anciens (modérateur and co).
Si tu te retrouves avec plein de personnes qui viennent aider et au bout de qqs semaines, tu les vois plus. Il faut reprendre leur travail, arriver a comprendre, c’est du boulot. Je pense qu’ils cherchent des personnes qui sont là pour les aider depuis longtemps ou qui s’investissent naturellement. Je pense a @Thibaut_T qui a aidé Loïc dans le débug d’un plugin. Rien qu’à toi de commencer petit et voir ensuite. Ce n’est que mon avis personnel.
Fonctions sensibles, merci de tester !!
