Je tente de débroussailler #5566, et je souhaite partager cela sur le dépôt officiel pour inviter plus de monde à tester, faire des retours, valider les nouveaux concepts…
Les PR depuis les bifurcations perso, ça sert à ça me direz vous !
Oui… mais le chantier est d’une telle ampleur (core + plugins-dist) qu’il s’étalera nécessairement sur plusieurs mois. Du coup, je voudrais adresser les PR dans une branche dédiée, plutôt que dans master (jusqu’à atteindre une certaine stabilité au moins, et l’imminence de SPIP5),
D’où ma requête auprès d’un admin :
Création d’une branche dev/issue_5566_plainjs sur le core.
Création d’une branche dev/core_issue_5566_plainjs sur chaque plugins-dist.
Salut et une fois de plus merci pour ton travail sur ce chantier !
Quelle serait la facilité que cela pourrait t’apporter ? Car, tant que la PR ne sera pas mergée, tu devras mettre à jour tes forks, et si on met en place une branché dédiée à l’accueil de tes PRs, nous devrons aussi mettre à jour ces branches. Je ne comprends pas vraiment l’intérêt.
Je comprends bien que c’est une démarche particulière ; mais prenons le problème à l’envers. En admettant que les PR se fassent sur master, compte tenu du nombre de commits sous-jacents au projet (plus d’une cinquante sur ma branche déjà à ce jour), ça risque d’être durs de faire le tri entre les fix et features de la release classique, et ceux qui sont surdéterminés par le nouveau paradigme des modules (enfin sauf si je reste le seul à travailler sur cette fonctionnalité ).
C’est une histoire de compartimentation en fait. Idem pour les plugins-dist (comment faire le tri des commits au long cours et ceux qui reposent sur le nouveau paradigme importmap sans se perdre ?)
Ces branches temporaires doivent en effet se tenir à jour vis-à-vis de master, c’est un peu contraignant certes, mais il me semble plus favorable de concentrer la contrainte sur la branche dédiée, au profit d’une gestion plus simple sur master.
En outre, cette approche de branche dédiée ne serait que temporaire, le temps de gagner en maturité et avancer sur l’ensemble des plugins-dist avant de faire une fusion sur chaque branche principale.
Bon après si le projet trouve de l’engouement, et qu’on pense pouvoir l’intégrer de manière satisfaisante entre 4.3 et 5.0, alors peut-être, en effet, on peut rester focaliser sur master, mais il faut être conscient de ce que cela implique.
Je me range à l’avis des personnes en charge de la maintenance.
Bon, ma demande semble trop saugrenue. Alors on va faire autrement.
Je pense que je vais attendre la sortie de la 4.3 avant de formuler la PR, sur master donc.
Et le jour où la fusion sur master est opérée, ouvrir les quelques tickets corollaires sur les plugins-dist qui permettent de stabiliser le tout ; notamment déplacer la surcharge d’une fonction du compresseur dans le plugin idoine.
Il y a aussi l’éventualité (à confirmer) de rassembler le code de chargement de jQuery, et la lib elle-même, dans un nouveau plugin-dist ; et bien d’autres points … à traiter dans des tickets séparés, à ce moment là donc.
).