- Este debate está vacío.
-
Entradas
-
Hola,
¿ Cual es el mecanismo para enviar parches con modificaciones al código o conseguir acceso de escritura al repositorio ?
Saludos,
Saulo
Buenas,
Ante todo, gracias por el interés en contribuir para mejorar Libertya.
Si bien todavía no hay una metodología 100% formal, dado que el repositorio es público (alojado en Google Code), podrías levantar un issue adjuntando el patch correspondiente a una revisión específica con los cambios a aplicar. De todas maneras existe la limitación cuando las mejoras incluyen modificaciones al diccionario de datos de Libertya.
Para esto último ya sería necesario un nivel de formalidad (e interacción) mayor, en el que se define un componente temporal de desarrollo en donde se incluyen cambios de código, sql y modificaciones de metadatos, para luego crear un .jar definitivo que luego de ser validado se incorpora al CORE de libertya.
Cualquier inquietud, no dudes en consultar.
Saludos,
FedericoMuchas gracias Federico. Les estaré generando tickets entonces, con parches (svn diff) a medida que vayan surgiendo cosas.
Saludos
Federico,
Nosotros en google projects, en los issues, adjuntamos alguna modificación de código sobre las cuentas corrientes en la nueva versión..hay alguna forma de enterarnos si alguien las revisó y obtener una devolución sobre eso?
Muchas Gracias!!!
Buenas,
Ante todo, muchas gracias por los aportes!
Actualmente estamos haciendo las gestiones pertinentes para implementar un procedimiento interno que nos permita ir consumiendo paulatinamente los issues cargados en Google Code, y a medida que se vayan resolviendo/incorporando/etc. a LY, vamos a brindar el correspondiente feedback en el issue en cuestión.
En resumen: aunque estamos en una etapa inicial de esta iniciativa, la intención es mejorar LY lo más posible, aprovechando ademas la buena voluntad de la comunidad, y como siempre manteniendo la interacción lo más fluida entre ambas partes, en este caso a través de los issues en Google Code.
Saludos!!
FedericoHola Federico,
Una configuración típica utilizada en proyectos open source es dar acceso de escritura a los branches del repositorio, a cada contribuyente que lo solicite.
El acceso de escritura a trunk solo lo tiene un grupo selecto que tiene la autoridad para aprobar o rechazar los cambios.
Este esquema facilita el desarrollo a los contribuyentes ya que no tienen que armarse un repositorio aparte para trabajar de forma ordenada. También es más facil para los administradores del proyecto ya que no tienen que estar trabajando con parches (potencialmente grandes), se facilita el testing de los cambios y la integración hacia trunk.Dicho esto, como recomendación personal les sugiero migrar el repositorio a GIT ya que es mucho mejor para trabajar colaborativamente para este y otros proyectos (e.g.: localización Argentina de Adempiere). Se que esto no suele ser facil ya que muchas veces hay varias cosas “colgando” del tipo de repositorio (e.g.: build scripts) que deben adaptarse para poder migrar.
Quizás también le podamos sacar provecho al hecho de que casi todos los miembros de la comunidad estamos en la misma zona horaria y hablamos el mismo lenguaje. Quizás se puedan organizar meetings (presenciales o con algun sistema tipo skype) regulares para ver el estado de las cosas (e.g.: tickets pendientes, cambios grandes en el sistema, preparar releases, etc)
Saludos,
Saulo
Buenas,
Ante todo gracias por las sugerencias y comentarios.
Respecto al acceso y uso de branches, justamente estamos definiendo una metodología similar a la que mencionas, contemplando además la complejidad que implica un producto altamente basada en metadatos.
En lo que refiere al uso de Git, si bien hemos evaluado su utilización y entendemos los beneficios de Git, varios aspectos de SVN – como el número de revisión centralizado – simplifican la gestión y mantenimiento de componentes, asociado ésto con el historial de cambios en los metadatos.
Saludos,
Federico¿ Tienen alguna novedad al respecto ? Si están trabados con algo quizás lo podamos ver entre todos. Entiendo que no es fácil lograr un esquema que permita la coexistencia entre las releases oficiales y las customizaciones de cada uno, pero creo que alguna vuelta tiene que haber.
Actualmente no se está aceptando ninguna contribución por parte de la comunidad ni se ofrece feedback. De la misma forma no hay feedback para los bugs reportados en Google Code. Creo que sería la ironía más grande si se repite la historia de Compiere …
Pensando a largo plazo creo que el que surjan proyectos similares a este va a ser solo cuestión de tiempo, solo van a tener un mejor desempeño quienes brinden un soporte real a la comunidad y sepan capitalizar ese potencial (algo que no se ve reflejado actualmente).
Buenas!
Ante todo, disculpas por la demora en la respuesta, hemos estado ultimando los detalles para poder brindar las facilidades necesarias de desarrollo a los eventuales colaboradores.
Para ésto se definió una metodología de desarrollo para colaboradores, la cual se encuentra detallada en este artículo de la wiki para desarrolladores Libertya.
Es de esperar que con ésto se logre una “autonomía de desarrollo” para los colaboradores, quienes contarán en todo momento con los fuentes LY + BBDD libertya CORE actualizados. Luego simplemente es cuestión de acordar objetivo y alcance de los eventuales desarrollos a aportar; para eventualmente llevar dicha funcionalidad al CORE de Libertya si el desarrollo así lo amerita.
Invitamos entonces a todo el que esté interesado en mejorar Libertya a interiorizarse en la metodología propuesta y a trabajar en los temas que les sean de interés en el marco del proyecto.
Respecto de los bugs reportados en Google Code, la intención es poder revisarlos y resolver la mayor cantidad posible antes del nuevo release (principios 2014). Obviamente, también aquí cualquier aporte es bienvenido.
Esperamos vuestros comentarios.
Saludos!
Federico
- Debes estar registrado para responder a este debate.
