Partkeepr: proceso de desarrollo de nueva versión

No se han realizado confirmaciones desde el 20 de julio de 2018. Así que creo que no estamos hablando de ETA para el próximo lanzamiento, sino de ETA para un nuevo desarrollador principal. Hasta que tengamos uno, no tendremos ningún lanzamiento seguro. Sin embargo, me gustaría saber cuál es el estado actual.

La información más reciente del proyecto está aquí: https://www.patreon.com/posts/its-end-for-me-22527966
Y básicamente el proyecto ya no tiene mantenedor, pero si alguien en serio quiere tomarlo, parece posible.

Entonces @christianlupus tiene razón, en realidad es ETA hasta que haya un nuevo

.

Tener 5 desarrolladores es probablemente más que inútil sin una gestión de proyectos sólida (y probablemente financiación en esta etapa), el proyecto puede sobrevivir con uno o dos, y el único problema resultante puede ser el tiempo de desarrollo.

Un tema que señaló es bastante claro: la gestión de problemas y el manejo de personas con mal comportamiento.

El proyecto puede vivir felizmente con dos desarrolladores, incluso con problemas de salud, siempre y cuando haya personas que se encarguen del triaje de problemas y la gestión de la comunidad para que los desarrolladores puedan concentrarse en una tarea sin tener que preocuparse por otras cosas.

.

PartKeepr habría utilizado otro marco más, el mismo argumento se aplicaría, Symphony no es realmente un marco de nicho.

Sí, necesita a alguien que lo sepa o esté dispuesto a aprenderlo, como cualquier otro marco.

Y sí, podría ser una aplicación de nicho, pero el contexto es para tener en cuenta, si conocieras Symphony, ¿estarías motivado para unirte a un proyecto que parece muerto? Probablemente no.

.

¿Realmente necesita un marco avanzado listo para usar?

No es más avanzado que otro, es solo un framework, sí puedes usar uno muy ligero, pero al final del día habrás agregado un montón de extensiones o las habrás hecho desde cero para el mismo resultado, e incluso peor, ya que no estará tan documentado y probado como el "marco avanzado listo para usar".

Pero arreglar esas soluciones de una manera agradable necesitaría un gran rediseño, probablemente no sea factible con el marco Symphony o cualquier otro estándar disponible.

No estamos hablando de aplicaciones Win32 aquí, y a menos que tenga un POC para demostrar que no es factible con el marco actual, entonces es BS.
Reinventar la rueda puede funcionar a veces, pero esa no es una solución que funcione siempre.

Si dice que "la curva de aprendizaje de la sinfonía es demasiado empinada", ¿cómo se supone que una cosa hecha a medida es mejor?

Ahora despotricar que "la sinfonía es mala y el proyecto está condenado al fracaso a menos que reescribamos todo" no hará que el proyecto avance más, trabajar en las relaciones públicas y con los contribuyentes sí lo es.

.

Si, por ejemplo, me gustaría tener categorías con especificaciones en cascada, que también se conectan en cascada a componentes dentro de dicha categoría (con la posibilidad de anularlos). Y que mostrar una descripción formateada agradable de todas las especificaciones combinadas dependiendo del tipo de componente. ¿Es algo que debería esperar que funcione en Symfony?

No. Ningún marco hará eso. Creo que no entiende lo que es un marco. La implementación de Categorías es algo específico de la aplicación, y ningún marco genérico lo manejará.

No creo que Symphony u otros frameworks sean malos. Pero en el caso de cómo me gustaría que se viera un Sistema de Gestión de Inventario, es muy poco probable que hagan el corte. Eso no es una tontería, sino una buena comprensión de la complejidad involucrada.

¿Qué diablos tiene un marco que ver con una aplicación específica? Ningún marco comprende cómo funciona una aplicación. Proporciona un esquema, una filosofía y un modelo sobre los que basarse.

Nota adicional: Sí, todavía tengo que transferir los derechos de acceso al repositorio a alguien, desafortunadamente estoy bastante ocupado con la liquidación de PartKeepr UG. Espero llegar pronto a eso

.

Hola felicia

Mi comprensión de Symphony como marco -como decía- es limitada. Pero, por ejemplo, si está creando vistas de IU leyendo directamente de tablas, consultas, es bastante difícil mostrar información que está vinculada de forma avanzada entre sí.

En ese caso, podría ser mejor leer qué ofrece Symfony y qué no, en lugar de hacer suposiciones falsas. No hay vistas de IU generadas por Symfony, al menos no en PartKeepr.

La información heredada y en cascada propuesta es difícil de consultar y, por lo tanto, probablemente difícil de procesar mediante un marco (controlado por tablas), ¿o estoy entendiendo mal las cosas?

Sí, estás malinterpretando las cosas. Symfony no proporciona tales cosas, tal vez a través de algún paquete de terceros, pero nuevamente, PartKeepr no usa dicho paquete. Symfony se usa principalmente para la arquitectura del controlador, las funciones de serialización (que, en conjunto, usan la plataforma API para generar JSON-LD que luego puede ser leído por la interfaz) y Doctrine para todo lo relacionado con la base de datos.

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

.

Hola felicia

Gracias por responder. He programado muchas cosas, incluso la tecnología web en sus inicios. Pero eso es bastante deficiente en lo que respecta a la comprensión de la arquitectura de PartKeepr. Además, las diferentes tecnologías utilizadas son difíciles de comprender como desarrollador de Windows. Como dije, para mí, la curva de aprendizaje es demasiado empinada. Pero la pregunta subyacente aún puede ser válida. ¿Cuáles son los objetivos de desarrollo y pueden alcanzarse con las tecnologías utilizadas? Independientemente de cómo se llamen.

Razones para utilizar un marco, especialmente un marco ampliamente utilizado, adoptado y mantenido como Symfony2:

• Evite la duplicación de código
• Aumentar la confiabilidad
• No reinventes la rueda
• Incrementar la mantenibilidad
• Reducir el trabajo

Hasta PartKeepr 0.1.9, no usaba un marco aparte de Doctrine para la persistencia (Symfony2 no existía en ese entonces). El mantenimiento fue una pesadilla.

La razón por la que no hay inyecciones SQL en PartKeepr es por Doctrine. La razón por la que hubo tantas características nuevas después de la versión 0.1.9 en poco tiempo fue Symfony2 y la plataforma API debido a la sobrecarga de desarrollo extremadamente baja. La razón por la que PartKeepr funciona detrás de un proxy inverso sin que yo escriba código cero para admitirlo: Symfony2. La razón por la que PartKeepr funciona en nginx sin ninguna modificación de código: Symfony2.

Si tienes problemas para entender cómo funciona Symfony2, no hay problema: hay muchos recursos en la web para ayudarte.

Si PartKeepr usara su propio marco, estaría completamente solo, incluso para la funcionalidad más básica. Recientemente, eché un vistazo a The Bug Genie como un rastreador de problemas, y no usa un marco en absoluto, todo está escrito por mí mismo. Envié no menos de 8 solicitudes de extracción para corregir errores que encontré durante el uso normal. Después de encontrarme con media docena de errores más (y solo usé el software durante unos 30 minutos durante un período de un mes), dejé de usarlo.

Creo que probablemente eres la mejor persona para dar la respuesta por qué este proyecto ha tenido tan poco apoyo para el desarrollo. Y si es reparable.

Solo puedo adivinar: una base de usuarios relativamente pequeña y cumplí demasiadas solicitudes de funciones. Funcionó de inmediato para la mayoría de los usuarios, entonces, ¿por qué estos usuarios comenzarían a contribuir con código?

Las preguntas que me hago son: ¿me gustaría participar en un proyecto compartido? ¿Se beneficiaría de mi experiencia? ¿Comparten más personas mis objetivos? ¿Cómo serían las interacciones entre desarrolladores?

A menos que esté dispuesto a aprender cómo funcionan un proyecto de software y las tecnologías subyacentes, no mucho. Dar un paso adelante y quejarse de la elección del marco es un primer paso muy malo.

No participaré en ningún proyecto o coordinación de desarrollo en este proyecto.

Actualmente estoy intentando actualizar a Symfony 3.4. si logro algún progreso, daré una actualización

Hola @JelleDijkhuizen
¿Tienes alguna novedad sobre la migración de Symfony 3.x? Si ha trabajado en esto, ¿podría decirme dónde puedo encontrar su tenedor? ¡Gracias por adelantado!

@martonmiklos , parece que @adlerweb está intentando actualizar PartKeepr a Symphony 4 en una rama dedicada de su bifurcación ... :-)

@ZupoLlask ¡ gracias por el

Creo que esta discusión fue larga y el tema principal está aclarado. Vea el n. ° 1059. Así que cerraré esto por ahora.