search

scanterra / geonode

GeoNode is an open source platform that facilitates the creation, sharing, and collaborative use of geospatial data.
https://waffle.io/geosolutions-it/geonode
GNU General Public License v3.0
0 stars 0 forks source link

Problema con la versión de Geonode en la rama `develop` #2

Open LaimeJesus opened 4 years ago

LaimeJesus commented 4 years ago

La rama develop está en un estado diferente al implementado en los servidores CRESUD, PROD y CLON_PROD, por eso necesitamos cambiarla por una que refleje lo que realmente estamos usando para mantener la consistencia de versiones de Geonode que estamos utilizando. Por lo tanto tenemos que cambiar la rama develop por la rama prod-backup o una similar, como por ejemplo, 2.7.x.

En conclusión, tenemos que:

Esto habilitaría a integrar los cambios de las siguientes ramas, que fueron cambios hechos a geonode a partir de la rama prod-backup

Comentado en este PR: #1

asassano commented 4 years ago

@LaimeJesus 1- de dónde conviene más crear la nueva rama de la 2.7.x , de la 2.7.x-risks o de prod-backup?? 2- Te parece que le ponga el nombre "develop_prod" o "develop_2.7.x?? o que nombre sugieren para poder darle continuidad y que tenga lógica?? 3- Y por otro lado, no convendría ya usar el repo original de la comunidad https://github.com/GeoNode que es el oficial y el que en teoría es más estable?? en vez de usar este que es de otra empresa?? si es así, me avisan, hago el fork o si creen conveniente mejor un clone y listo, configuro todo y listo. @cristiandley lo podes mirar también y darme tu sugerencia?? Gracias

cristiandley commented 4 years ago

@asassano @LaimeJesus

Esto habilitaría a integrar los cambios de las siguientes ramas, que fueron cambios hechos a geonode a partir de la rama prod-backup

Jesus, estos cambios fueron ya analizados por GeoNode oficial y nosotros los pasamos al fork o son 100% propios ?.

2- Te parece que le ponga el nombre "develop_prod" o "develop_2.7.x?? o que nombre sugieren para poder darle continuidad y que tenga lógica??

Yo no crearia variantes de la rama develop (develop_prod o develop_2.7.x). Si N clientes utilizan N versiones se puede administrar por las ramas de esas releases. (entiendo ya son versiones estables, que solo podrian requerir configuracion interna y no necesitan una etapa de develop).

3- Y por otro lado, no convendría ya usar el repo original de la comunidad https://github.com/GeoNode que es el oficial y el que en teoría es más estable?? en vez de usar este que es de otra empresa?? si es así, me avisan, hago el fork o si creen conveniente mejor un clone y listo, configuro todo y listo.

En que varia un Fork de GeoNode puro a lo que hoy tenemos implementado ?. Solo la configuracion interna ? o Kartoza tiene customs dentro ?.

LaimeJesus commented 4 years ago

@LaimeJesus 1- de dónde conviene más crear la nueva rama de la 2.7.x , de la 2.7.x-risks o de prod-backup??

El camino seguro es usar la rama prod-backup, la rama "2.7.x" sigue la misma historia de commits que prod-backup pero tiene varios commits más actualizados, nosotros no investigamos en cuánto influyen esos cambios hechos en Geonode.

2- Te parece que le ponga el nombre "develop_prod" o "develop_2.7.x?? o que nombre sugieren para poder darle continuidad y que tenga lógica?? Yo no crearia variantes de la rama develop (develop_prod o develop_2.7.x). Si N clientes utilizan N versiones se puede administrar por las ramas de esas releases. (entiendo ya son versiones estables, que solo podrian requerir configuracion interna y no necesitan una etapa de develop).

Opino igual que Cristian. No conviene tener variantes, tenemos que dejar el repositorio lo más prolijo posible.

En que varia un Fork de GeoNode puro a lo que hoy tenemos implementado ?. Solo la configuracion interna ? o Kartoza tiene customs dentro ?.

El problema que tenemos ahora es la versión de Geonode a usar y desde cuál vamos a seguir trabajando. Para entender rápidamente, en Scanterra tenemos dos repositorios que usan Geonode:

La parte importante de entender es que los cambios implementados en geonode se hacen desde el repo geonode_generic. Este repositorio agrega algunos módulos Django y configuraciones generales a la app, como permisos específicos, etc, con estos cambios no habría ningún problema porque son externos a Geonode. El problema radica en que también modifica(sobrescribe) archivos específicos de Geonode(ver archivo deployment/production/overrides-geonode.sh), los pisa literalmente, esto imaginamos que era necesario para dejar estos cambios por fuera del repositorio oficial de Geonode y lograr migrar a versiones nuevas sin tener conflicto con esos archivos. Con @marcelorubini vimos que esto solo nos dejaría mucho más trabajo para hacer en un futuro ya que deberíamos mantener diferentes versiones de código al mismo tiempo, una en geonode y otra en geonode_generic.

Los customs de kartoza son estas modificaciones mensionadas.

3- Y por otro lado, no convendría ya usar el repo original de la comunidad https://github.com/GeoNode que es el oficial y el que en teoría es más estable?? en vez de usar este que es de otra empresa?? si es así, me avisan, hago el fork o si creen conveniente mejor un clone y listo, configuro todo y listo.

No cambia nada usar el repositorio oficial de Geonode, lo que tenemos que tener en cuenta es cuál es la versión de Geonode a usar. Nosotros sabemos que prod-backup funciona, y que la rama "2.7.x" sigue la misma historia, entonces de ahora en más Scanterra tiene que seguir usando esas versiones de código. Si en un futuro queremos migrar, ya sabríamos desde dónde tenemos que hacer los cambios.

cristiandley commented 4 years ago

  • geonode(forkeado de IT-solutions)

  • geonode_generic(implementado por Kartoza)

Para entender mejor:

geonode_generic implementa y agrega cambios a la build de GeoNode, es asi ?. O los dos repositorios son independientes uno de otro y mantienen versiones propias ?.

Deje un issue porque el readme de geonode_generic tiene el template por default.

El problema radica en que también modifica(sobrescribe) archivos específicos de Geonode(ver archivo deployment/production/overrides-geonode.sh), los pisa literalmente, esto imaginamos que era necesario para dejar estos cambios por fuera del repositorio oficial de Geonode y lograr migrar a versiones nuevas sin tener conflicto con esos archivos. Con @marcelorubini vimos que esto solo nos dejaría mucho más trabajo para hacer en un futuro ya que deberíamos mantener diferentes versiones de código al mismo tiempo, una en geonode y otra en geonode_generic.

El hotfix que se agrega ahora es lo que inyecta Kartoza en generic o es otra cosa ?

No cambia nada usar el repositorio oficial de Geonode, lo que tenemos que tener en cuenta es cuál es la versión de Geonode a usar. Nosotros sabemos que prod-backup funciona, y que la rama "2.7.x" sigue la misma historia, entonces de ahora en más Scanterra tiene que seguir usando esas versiones de código. Si en un futuro queremos migrar, ya sabríamos desde dónde tenemos que hacer los cambios.

No seria mejor ir por un fork oficial que tenga update por el bot ? Digo parece que geosolutions-it no actualiza desde Marzo 5 master.

Alguno sabe por que la 2.7.X solo aparece en geosolutions-it como branch ?

LaimeJesus commented 4 years ago
  • geonode(forkeado de IT-solutions)
  • geonode_generic(implementado por Kartoza)

Para entender mejor:

geonode_generic implementa y agrega cambios a la build de GeoNode, es asi ?. O los dos repositorios son independientes uno de otro y mantienen versiones propias ?.

Son dos repositorios independientes, geonode_generic agrega módulos nuevos para usar dentro de Django, y además modifica algunos archivos específicos de Geonode.

Deje un issue porque el readme de geonode_generic tiene el template por default.

Ya teníamos escrito un README, que entendemos se pisó con el rebase de develop. Luego corregimos eso.

El problema radica en que también modifica(sobrescribe) archivos específicos de Geonode(ver archivo deployment/production/overrides-geonode.sh), los pisa literalmente, esto imaginamos que era necesario para dejar estos cambios por fuera del repositorio oficial de Geonode y lograr migrar a versiones nuevas sin tener conflicto con esos archivos. Con @marcelorubini vimos que esto solo nos dejaría mucho más trabajo para hacer en un futuro ya que deberíamos mantener diferentes versiones de código al mismo tiempo, una en geonode y otra en geonode_generic.

El hotfix que se agrega ahora es lo que inyecta Kartoza en generic o es otra cosa ?

Es algo nuevo.

No cambia nada usar el repositorio oficial de Geonode, lo que tenemos que tener en cuenta es cuál es la versión de Geonode a usar. Nosotros sabemos que prod-backup funciona, y que la rama "2.7.x" sigue la misma historia, entonces de ahora en más Scanterra tiene que seguir usando esas versiones de código. Si en un futuro queremos migrar, ya sabríamos desde dónde tenemos que hacer los cambios.

No seria mejor ir por un fork oficial que tenga update por el bot ? Digo parece que geosolutions-it no actualiza desde Marzo 5 master.

Ahora que estamos seguros que versión estamos usando podemos pensar en qué estrategia usar. Pero aún no estamos en condiciones de actualizar la versión de Geonode sin ver el impacto de cambios que tiene usarlo junto a geonode_generic.

Alguno sabe por que la 2.7.X solo aparece en geosolutions-it como branch ?

No sabemos, es la versión que usaban la gente de Kartoza.

LaimeJesus commented 4 years ago

Para definir cómo continuar, vemos que la opción indicada es usar la rama prod-backup como develop, y pensar de ir actualizando hacia la rama "2.7.x" en adelante.

En definitiva:

asassano commented 4 years ago

@LaimeJesus @cristiandley @marcelorubini Después de charlar y evaluar varias cosas y para intentar acomodar bien las cosas de una propongo:

1- [@asassano ] Frok comunidad oficial https://github.com/GeoNode

2- [@asassano ] Crear rama vacía (borrar todo lo que haya) "develop-prod-backup" y

3- [@LaimeJesus ] subir todo lo de la rama prod-backup.

4- [@asassano ] Generar los READMEs, templates de issues y CODEOWNERS en la nueva rama develop.

5- [@LaimeJesus ] Generar los PRs con los cambios implementados en CRESUD en la nueva rama develop. (RECORDAR QUE SCANTERRA PRODUCCIÓN TIENE QUE SER IGUAL A CRESUD EN FUNCIONALIDADES PERO CON LOOK AND FEELD DISTINTO)

6- [@asassano ] Crear otra rama vacía (borrar todo lo que haya) "2.7.x-original-geosolutionIT" y subir todo lo de la rama 2.7.x del repo de geosolution. Para poder comparar si hace falta con esta o ya con cualquier rama superior de la comunidad.

LaimeJesus commented 4 years ago

@LaimeJesus @cristiandley @marcelorubini Después de charlar y evaluar varias cosas y para intentar acomodar bien las cosas de una propongo:

1- [@asassano ] Frok comunidad oficial https://github.com/GeoNode OK

2- [@asassano ] Crear rama vacía (borrar todo lo que haya) "develop-prod-backup" y OK 3- [@LaimeJesus ] subir todo lo de la rama prod-backup. OK

4- [@asassano ] Generar los READMEs, templates de issues y CODEOWNERS en la nueva rama develop. OK

5- [@LaimeJesus ] Generar los PRs con los cambios implementados en CRESUD en la nueva rama develop. (RECORDAR QUE SCANTERRA PRODUCCIÓN TIENE QUE SER IGUAL A CRESUD EN FUNCIONALIDADES PERO CON LOOK AND FEELD DISTINTO) OK

6- [@asassano ] Crear otra rama vacía (borrar todo lo que haya) "2.7.x-original-geosolutionIT" y subir todo lo de la rama 2.7.x del repo de geosolution. Para poder comparar si hace falta con esta o ya con cualquier rama superior de la comunidad. OK

asassano commented 4 years ago

@LaimeJesus @cristiandley no me deja hacer un fork directo del de la comunidad porque ya tenemos un fork de geosolution-it que este último a su vez es un fork de de la comunidad. Que sugieren?? Ustedes tiene todos los cambios y commint a nivel local?? porque lo que se podría hacer es descargarlo por las dudas y borrarlo y ahí hacer el fork directo de la comunidad. Pero @LaimeJesus confirmame si tiene todo guarda a nivel local? image

LaimeJesus commented 4 years ago

@LaimeJesus @cristiandley no me deja hacer un fork directo del de la comunidad porque ya tenemos un fork de geosolution-it que este último a su vez es un fork de de la comunidad. Que sugieren?? Ustedes tiene todos los cambios y commint a nivel local?? porque lo que se podría hacer es descargarlo por las dudas y borrarlo y ahí hacer el fork directo de la comunidad. Pero @LaimeJesus confirmame si tiene todo guarda a nivel local? image

Tenemos el repositorio a nivel local, si eliminas el repositorio se van a perder los issues y los PRs creados. Antes de borrar el repositorio deberíamos tener una copia de esto.

asassano commented 4 years ago

ok, el PR lo puedo imprimir para no perder el aprendizaje pero entiendo que igual no sirve más. Y el Issue lo puedo transferir o copiar a otro Repo provisorio hasta dar de baja este repo y forkear el de la comunidad. Están de acuerdo?? @LaimeJesus @cristiandley

cristiandley commented 4 years ago

@asassano @LaimeJesus Este repositorio no lo podemos renombrar ? como geonode__legacy ? y asi poder forkear y mantener hasta tanto saber que no requerimos del mismo.

asassano commented 4 years ago

Para definir cómo continuar, vemos que la opción indicada es usar la rama prod-backup como develop, y pensar de ir actualizando hacia la rama "2.7.x" en adelante.

En definitiva:

  • [@asassano ] Borrar la rama develop. HECHO
  • [@asassano ] Crear una nueva rama develop a partir de prod-backup. HECHO
  • [@asassano ] Generar los READMEs, templates de issues y CODEOWNERS en la nueva rama develop. HECHO + APLICAR REGLAS
  • [@LaimeJesus ] Generar los PRs con los cambios implementados en CRESUD en la nueva rama develop.
  • Definir la estrategia de actualización de la versión actual de Geonode usada en Producción.

SE DEFINIÓ IMPLEMENTAR ESTO POR AHORA, HASTA ASEGURARNOS QUE ANDE BIEN PERO, SE MIGRAR LA ÚLTIMA VERSIÓN A REPO DE LA COMUNIDAD DENTRO DE ESTE PROYECTO AL FINALIZAR Y ASEGURAR QUE TODOS LOS COMMITS Y RAMAS FUNCIONEN CORRECTAMENTE. Acordado con @LaimeJesus @cristiandley

@LaimeJesus Consulta: La rama master y release también hay que borrarlas y crearlas desde la "nueva develop" (creada de prod-backup)??

marcelorubini commented 4 years ago

Para definir cómo continuar, vemos que la opción indicada es usar la rama prod-backup como develop, y pensar de ir actualizando hacia la rama "2.7.x" en adelante. En definitiva:

  • [@asassano ] Borrar la rama develop. HECHO
  • [@asassano ] Crear una nueva rama develop a partir de prod-backup. HECHO
  • [@asassano ] Generar los READMEs, templates de issues y CODEOWNERS en la nueva rama develop. HECHO + APLICAR REGLAS
  • [@LaimeJesus ] Generar los PRs con los cambios implementados en CRESUD en la nueva rama develop.
  • Definir la estrategia de actualización de la versión actual de Geonode usada en Producción.

SE DEFINIÓ IMPLEMENTAR ESTO POR AHORA, HASTA ASEGURARNOS QUE ANDE BIEN PERO, SE MIGRAR LA ÚLTIMA VERSIÓN A REPO DE LA COMUNIDAD DENTRO DE ESTE PROYECTO AL FINALIZAR Y ASEGURAR QUE TODOS LOS COMMITS Y RAMAS FUNCIONEN CORRECTAMENTE. Acordado con @LaimeJesus @cristiandley

@LaimeJesus Consulta: La rama master y release también hay que borrarlas y crearlas desde la "nueva develop" (creada de prod-backup)??

@asassano OK! algunos pasitos extras que podemos implementar para dejar aún mas prolijo todo:

marcelorubini commented 4 years ago

@asassano favor de confirmar cuando las tareas sobre master hayan sido realizadas para cerrar este issue.

SE DEFINIÓ IMPLEMENTAR ESTO POR AHORA, HASTA ASEGURARNOS QUE ANDE BIEN PERO, SE MIGRAR LA ÚLTIMA VERSIÓN A REPO DE LA COMUNIDAD DENTRO DE ESTE PROYECTO AL FINALIZAR Y ASEGURAR QUE TODOS LOS COMMITS Y RAMAS FUNCIONEN CORRECTAMENTE. Acordado con @LaimeJesus @cristiandley @LaimeJesus Consulta: La rama master y release también hay que borrarlas y crearlas desde la "nueva develop" (creada de prod-backup)??

@asassano OK! algunos pasitos extras que podemos implementar para dejar aún mas prolijo todo:

  • eliminar la rama prod-backup. ya no tiene sentido seguir manteniendola.
  • eliminar la rama master y recrearla a partir de la nueva develop. como bien consultabas.

  • en cuanto a la rama release, no creemos que vaya a ser necesaria mantenerla.

    • featurea/hotfix/release -> develop -> master el flujo queda mas que cubierto.