Open LaimeJesus opened 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
@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 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
odevelop_2.7.x
). SiN
clientes utilizanN
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 dedevelop
).
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.
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 ?
- 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 engeosolutions-it
como branch ?
No sabemos, es la versión que usaban la gente de Kartoza.
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:
@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 @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
@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?
@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?
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.
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
@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.
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)??
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:
prod-backup
. ya no tiene sentido seguir manteniendola.master
y recrearla a partir de la nueva develop
. como bien consultabas.release
, no creemos que vaya a ser necesaria mantenerla.
featurea/hotfix/release
-> develop
-> master
el flujo queda mas que cubierto.@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 nuevadevelop
. 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.
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 ramaprod-backup
o una similar, como por ejemplo,2.7.x
.En conclusión, tenemos que:
develop
develop
a partir deprod-backup
o2.7.x
.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