Partkeepr: processus de développement d'une nouvelle version

Aucun engagement n'a été fait depuis le 20 juillet 2018. Je pense donc que nous ne discutons pas d'ETA vers la prochaine version mais d'ETA avec un nouveau développeur principal. Tant que nous n'en aurons pas un, nous n'aurons pas de versions à coup sûr. Cependant, je serais curieux de savoir quel est l'état actuel.

Les dernières informations sur le projet sont ici : https://www.patreon.com/posts/its-end-for-me-22527966
Et fondamentalement, le projet n'a plus de mainteneur, mais si quelqu'un de sérieux veut le prendre, cela semble possible.

Donc @christianlupus a raison, c'est en fait ETA jusqu'au nouveau mainteneur.

.

Avoir 5 développeurs est probablement plus qu'inutile sans une gestion de projet solide (et probablement un financement à ce stade), le projet peut survivre avec un ou deux, et le seul problème qui en résulte peut être le temps de développement.

Un problème qu'elle a signalé est assez clair : la gestion des problèmes et la gestion des personnes ayant un mauvais comportement.

Le projet peut vivre avec bonheur avec deux développeurs, même avec un problème de santé, tant qu'il y a des personnes pour faire le triage des problèmes et la gestion de la communauté afin que les développeurs puissent se concentrer sur une tâche sans avoir à se soucier des autres choses.

.

PartKeepr aurait utilisé un autre framework, le même argument s'appliquerait, Symphony n'est pas vraiment un framework de niche.

Oui, il a besoin de quelqu'un qui le connaît ou est prêt à l'apprendre, comme tout autre framework.

Et oui c'est peut-être une application de niche, mais le contexte est à prendre en compte, si vous connaissiez la symphonie, seriez-vous motivé pour rejoindre un projet qui semble mort ? probablement pas.

.

A-t-il vraiment besoin d'un cadre avancé prêt à l'emploi ?

Ce n'est pas plus avancé qu'un autre, ce n'est qu'un framework, oui tu peux en utiliser un très léger, mais au final tu auras ajouté des tonnes d'extensions ou les aura fait de toutes pièces pour le même résultat, et même pire car il ne sera pas aussi documenté et testé que le "cadre avancé sur étagère".

Mais la correction de ces solutions de contournement nécessiterait beaucoup de refonte, probablement pas faisable avec le framework Symphony, ou tout autre standard.

Nous ne parlons pas ici d'applications Win32, et à moins que vous n'ayez un POC pour prouver que ce n'est pas faisable avec le framework actuel, alors c'est BS.
Réinventer la roue peut parfois fonctionner, mais ce n'est pas une solution qui fonctionne à chaque fois.

Si vous dites que "la courbe d'apprentissage de la symphonie est trop raide", comment un truc sur mesure est censé être meilleur ?

Maintenant, clamer que "la symphonie est mauvaise et le projet est voué à l'échec à moins que nous ne réécrivions tout" ne fera pas avancer le projet, travailler sur les relations publiques et avec les contributeurs l'est.

.

Si, par exemple, je souhaite avoir des catégories avec des spécifications en cascade, qui se répercutent également sur les composants de cette catégorie (avec la possibilité de les remplacer). Et que de montrer une belle description formatée de toutes les spécifications combinées en fonction du type de composant. Est-ce que quelque chose que je devrais m'attendre à travailler dans Symfony ?

Non. Aucun cadre ne le fera. Je pense que vous vous méprenez sur ce qu'est un cadre. L'implémentation des catégories est quelque chose de spécifique à l'application, et aucun framework générique ne pourra jamais gérer cela.

Je ne pense pas que Symphony ou d'autres frameworks soient mauvais. Mais dans le cas où j'aimerais qu'un système de gestion des stocks ressemble, il est très peu probable qu'il fasse l'affaire. Ce n'est pas de la BS, mais une bonne compréhension de la complexité impliquée.

Qu'est-ce qu'un cadre a à voir avec les travaux d'une application spécifique ? Tout framework ne comprend pas le fonctionnement d'une application. Il fournit un schéma, une philosophie et un modèle sur lesquels s'appuyer.

Note supplémentaire : Oui, je dois encore transmettre les droits d'accès au référentiel à quelqu'un, je suis malheureusement assez occupé avec la liquidation de PartKeepr UG. j'espère que j'y arriverai bientôt

.

Salut Félicia,

Ma compréhension de Symphony en tant que cadre -comme dit- est limitée. Mais par exemple, s'il crée des vues d'interface utilisateur en lisant directement à partir de tables, de requêtes, il est assez difficile d'afficher des informations liées de manière avancée les unes aux autres.

Dans ce cas, il serait peut-être préférable de lire ce que Symfony fournit ou non, au lieu de faire de fausses hypothèses. Il n'y a pas de vues d'interface utilisateur générées par Symfony, du moins pas dans PartKeepr.

Les informations en cascade et héritées proposées sont difficiles à interroger et donc probablement difficiles à traiter par un framework (conduit par table), ou est-ce que je comprends mal les choses ?

Oui, vous vous méprenez sur les choses. Symfony ne fournit rien de tel, peut-être via un bundle tiers, mais encore une fois, PartKeepr n'utilise pas un tel bundle. Symfony est principalement utilisé pour l'architecture du contrôleur, les fonctionnalités de sérialisation (qui, conjointement, utilisent la plate-forme API pour générer JSON-LD qui peut ensuite être lu par le frontend) et Doctrine pour tout ce qui concerne la base de données.

Voir https://wiki.partkeepr.org/wiki/Developers/Architecture

.

Salut Félicia,

Merci d'avoir répondu. J'ai programmé beaucoup de choses, même la technologie Web à ses débuts. Mais cela manque assez pour comprendre l'architecture de PartKeepr. De plus, les différentes technologies utilisées sont difficiles à appréhender en tant que développeur Windows. Comme dit pour moi la courbe d'apprentissage est trop raide. Mais la question sous-jacente peut toujours être valable. Quels sont les objectifs de développement, et peuvent-ils être atteints avec les technologies utilisées. Peu importe comment ils sont appelés.

Raisons d'utiliser un framework, en particulier un framework largement utilisé, adopté et maintenu comme Symfony2 :

• Éviter la duplication de code
• Augmenter la fiabilité
• Ne réinventez pas la roue
• Augmenter la maintenabilité
• Réduire le travail

Jusqu'à PartKeepr 0.1.9, il n'utilisait pas de framework en dehors de Doctrine pour la persistance (Symfony2 n'existait pas à l'époque). L'entretien était un cauchemar.

La raison pour laquelle il n'y a pas d'injections SQL dans PartKeepr est due à Doctrine. La raison pour laquelle il y avait tant de nouvelles fonctionnalités après la 0.1.9 en peu de temps était Symfony2 et la plate-forme API en raison de la surcharge de développement extrêmement faible. La raison pour laquelle PartKeepr fonctionne derrière un proxy inverse sans que j'écrive aucun code pour le prendre en charge : Symfony2. La raison pour laquelle PartKeepr fonctionne sur nginx sans aucune modification de code : Symfony2.

Si vous avez du mal à comprendre le fonctionnement de Symfony2, pas de problème : il existe de nombreuses ressources sur le Web pour vous aider.

Si PartKeepr utilisait son propre framework, vous seriez très seul, même pour les fonctionnalités les plus basiques. J'ai récemment jeté un œil à The Bug Genie en tant que traqueur de problèmes, et il n'utilise pas du tout de framework - tout est auto-écrit. J'ai soumis pas moins de 8 pull request pour corriger les bugs que j'ai rencontrés lors d'une utilisation normale. Après avoir rencontré une demi-douzaine de bugs supplémentaires (et je n'ai utilisé le logiciel que pendant peut-être 30 minutes sur une période d'un mois), j'ai arrêté de l'utiliser.

Je pense que vous êtes probablement la meilleure personne pour expliquer pourquoi ce projet a reçu si peu de soutien au développement. Et si c'est réparable.

Je ne peux que deviner : base d'utilisateurs relativement petite et j'ai répondu à trop de demandes de fonctionnalités. Cela a fonctionné immédiatement pour la majorité des utilisateurs, alors pourquoi ces utilisateurs commenceraient-ils à contribuer au code ?

Les questions que je me pose sont : aurais-je plaisir à participer à un projet partagé ? Cela profiterait-il de mon expérience? Est-ce que plus de gens partagent mes objectifs ? À quoi ressembleraient les interactions entre les développeurs.

À moins que vous ne souhaitiez apprendre comment fonctionnent un projet logiciel et les technologies sous-jacentes, pas grand-chose. Intensifier et se plaindre du choix du framework est un très mauvais premier pas.

Je ne participerai à aucun projet ou coordination de développement dans ce projet.

J'essaye actuellement de mettre à jour vers symfony 3.4. si je progresse, je donnerai une mise à jour

Salut @JelleDijkhuizen
Avez-vous des nouvelles de la migration vers symfony 3.x ? Si vous avez effectué des travaux sur ce sujet, pourriez-vous me dire où puis-je trouver votre fourchette ? Merci d'avance!

@martonmiklos , il semble que @adlerweb essaie de mettre à niveau PartKeepr vers Symphony 4 dans une branche dédiée de sa fourchette... :-)

@ZupoLlask merci pour l'

Je pense que cette discussion a été longue et que le problème principal est clarifié. Voir #1059. Donc, je vais fermer ça pour le moment.