Mi media center - Foro

Abro este hilo para coordinar un poco las diferentes líneas de desarrollo, en la medida de mis capacidades

Actualmente tenemos dos ramas:

1) develop-mediaserver: La versión de divadres, desde esta rama es con la que he publicado la versión actual mediaserver 4.0.8.
2) develop-limpieza-y-reorganización: La versión de mejoras y reestructuración interna. Tiene un conflicto en main-classic/platformcode/launcher.py, que he subido tal cual porque no se resolver.

Y quedan como PR pendientes de añadir en develop:

1) Servertools dinámico (https://github.com/tvalacarta/pelisalacarta/pull/153): Tiene conflictos para hacer un merge a develop.
2) Mejoras de superberny al buscador (https://github.com/tvalacarta/pelisalacarta/pull/157): También tiene conflictos para poder hacer un merge a develop.
3) Feature/tag in list item (https://github.com/tvalacarta/pelisalacarta/pull/181): Tiene conflictos para hacer un merge a develop.

Creo que los próximos pasos son:

1) Hacer el merge de las dos ramas en develop para empezar a probar, como no conozco en detalle los potenciales conflictos entre una y otra tendréis que echarme una mano.
2) Desarrollar sobre develop el nuevo sistema de actualizaciones de canales y servidores, para empezar haré el merge del PR153 sobre develop. Y al hilo de esto echaré un vistazo al servicio de Kampanita, para aprovechar lo que ha hecho e incorporarlo.
3) Y si la fuerza me acompaña, terminaré y subiré a develop una primera versión con Kivy sobre la que he estado trabajando.

El master queda con la versión 4.0.8 de momento, sin más cambios aparte de los últimos fixes.

Del servicio que he hecho no creo que puedas aprovechar mucho, porque se trata de un "upgrade" a lo bestia, es decir, sobreescribe todo.
* mira en git el tamaño del archivo pelisalacarta-master.zip
* compara con el zip de la version anterior
* si son diferentes, se baja el zip, saca la rama *master-classic" y la copia directamente en ".kodi/addons/plugin.video.pelisalacarta

Vamos, lo que hacia yo manualmente para estar al dia cuando veia que habias hecho algun merge nuevo .

Por eso te digo que no creo que haya nada aprovechable, ademas yo soy un poco bruto programando

Hola, estaba pensando donde preguntaros por la forma de trabajar sobre GiitHub y casualidad que hay un tema nuevo un poco relacionado, así que aprovecho para hacer unas preguntas.
Según tengo entendido lo que se suele hacer en GitHub es crear un branch del master y trabajar sobre dicho branch (a la vez que "tiras" del master por posibles cambios en el transcurso de tus modificaciones), y una vez has terminado y probado todo bajo tu branch haces un PR al master y luego prueban y si es decente se "mergea" y sale a la luz. Creo haberlo dicho bien (sino es asi agradecería una corrección), pero de lo que no estoy seguro es del branch al cual me debo "colgar", es decir, creo mi branch "nombrecualquiera" del branch "develop-limpieza-y-reorganización", "tvalacarta/develop-limpieza-y-reorganización", "master", "tvalacarta/master" o cual??
Si tu branch no se hace respecto a master, haces un PR y se "mergea" a "develop-limpieza-y-reorganización", después todo lo de ese branch se sube al master con un mega-PR??
Tenéis en cuenta cada modificación que hace cada contribuidor a la hora de "buscar" cambios en el repositorio remoto? Creo haber entendido que puedes comprobar solo si en el branch del que estas colgando hay modificaciones pero tambien puedes agregar a todo el que tenga un fork para tener en cuenta sus cambios, pero puede que lo haya entendido mal.
Cuando realizáis cambios puede suceder que dos personas modifiquen a la vez el mismo archivo y entonces se líe una buena, por que uno ha hecho un PR con cambios en la misma zona en la que el otro contribuidor estaba realizando otros cambios, y al hacer un pull este ultimo se encuentra el problema de tener que adaptarse. Tenéis algún procedimiento, registro o control para evitar lo máximo posible esas situaciones?

Veo que tenéis planeado crear lo de gestionar los canales, me alegro enormemente, porque desde que pensé la idea no he podido hacer mas que escribir el esquema, crear el archivo en markdown (me gusta el acabado final aunque no vaya a servir para nada ) y hace un rato he abierto su repositorio (que mañana cerrare ).

Os pido disculpas por mi ignorancia.
Un saludo y muchas gracias.

kerenmac escribió:Según tengo entendido lo que se suele hacer en GitHub es crear un branch del master y trabajar sobre dicho branch (a la vez que "tiras" del master por posibles cambios en el transcurso de tus modificaciones), y una vez has terminado y probado todo bajo tu branch haces un PR al master y luego prueban y si es decente se "mergea" y sale a la luz. Creo haberlo dicho bien (sino es asi agradecería una corrección), pero de lo que no estoy seguro es del branch al cual me debo "colgar", es decir, creo mi branch "nombrecualquiera" del branch "develop-limpieza-y-reorganización", "tvalacarta/develop-limpieza-y-reorganización", "master", "tvalacarta/master" o cual??

En primer lugar darte la bienvenida y decirte q practicamente todos somos nuevos en GIT/Github, asi q tampoco somos muy ortodoxos.
Jesus explico mas o menos como organiza el repositorio oficial en este hilo
Miratelo, pero resumiendo si tu propuesta es solo la cracion o modificacion de un canal/server puedes hacer PR directamente a la rama develop. Si por el contrario necesitas modificar otras partes del plugin debes crearte una rama de desarrollo (hija de develop) para q se pueda probar con tranquilidad.
¿q pasa si tu propuesta tiene como base una PR q aun no se haya mergeado a develop (como la rama develop-limpieza-y-reorganizacion? Aqui hablamos un poco de eso

kerenmac escribió:...después todo lo de ese branch se sube al master con un mega-PR??

Si una rama creada a partir de develop es aceptada se mergeara con develop y master para publicarla en la proxima version. De ello se encarga Jesus como 'Amo del Calabozo' Aunq es muy posible q surjan conflictos

kerenmac escribió:Tenéis en cuenta cada modificación que hace cada contribuidor a la hora de "buscar" cambios en el repositorio remoto? Creo haber entendido que puedes comprobar solo si en el branch del que estas colgando hay modificaciones pero tambien puedes agregar a todo el que tenga un fork para tener en cuenta sus cambios, pero puede que lo haya entendido mal.

Personalemente no (no se si alguien lo hace), lo q si hacemos es conversar con otros compañeros dentro de las PR sobre cambios q han hecho o q podrian hacer para integrarse mejor con lo q yo estoy haciendo. Vamos lo q viene siendo colaborar!!!

kerenmac escribió:Cuando realizáis cambios puede suceder que dos personas modifiquen a la vez el mismo archivo y entonces se líe una buena, por que uno ha hecho un PR con cambios en la misma zona en la que el otro contribuidor estaba realizando otros cambios, y al hacer un pull este ultimo se encuentra el problema de tener que adaptarse. Tenéis algún procedimiento, registro o control para evitar lo máximo posible esas situaciones?

Los temidos conflictos. Mirate esto

Muchas gracias por tu respuesta, me has aclarado muchísimas dudas. Creare una rama de desarrollo de la rama "develop" entonces. Si lo he entendido bien las ramas que creamos de nuestros forks en "develop" tienen como objetivo cambiar algo de "develop" y hacer pruebas sin alterar lo que pueda haber en "develop", en caso de que este bien hacemos un PR->merge en nuestro propio fork y posteriormente hacemos un PR a la rama "develop" oficial? Para hacer ese ultimo PR es necesario hacerlo desde GitHub o se puede hacer desde el software que uses para gestionar git (SurceTree, GitHub Desktop, ...)?
Actualmente estoy haciendo una pequeña modificación a library_service.py para facilitar la gestión de la misma serie con distintos canales (desde "archivos", per sin tocar nada relacionado con los .strm).

Un saludo y gracias!!

kerenmac escribió:Si lo he entendido bien las ramas que creamos de nuestros forks en "develop" tienen como objetivo cambiar algo de "develop" y hacer pruebas sin alterar lo que pueda haber en "develop", en caso de que este bien hacemos un PR->merge en nuestro propio fork y posteriormente hacemos un PR a la rama "develop" oficial?

Uyyyy Casi das el 100%!!!
Te explico como yo funciono (ya te dije q no somos expertos)
Cuando quiero hacer alguna propuesta de cambio me creo una sub-rama de develop (feature/my_nueva_rama) y cuando ya la tengo probada hago un fecth para bajarme los ultimos cambios del repositorio upstream (el de Jesus), mergeo mi rama Develop con la suya (ahora mi rama develop y la de Jesus tienen lo mismo) y subo mi rama feature/my_nueva_rama a mi github mediante push. Ahora ya puedo crear una PR (yo prefiero hacerlo desde github, pero sourcetree tb lo permite) y se ve si hay conflictos o no.
Si los hay toca solucionarlos en mi local (desde la rama feature/my_nueva_rama intentas mergear develop)
Cuando ya no haya conflictos creas la PR y esperas respuesta. Puedes continuar haciendo comits con mejoras en feature/my_nueva_rama q automaticamente se reflejaran en la PR. PERO NO LA ELIMINES NI INCORPORES (merge) A DEVELOP (pueden invertirse los polos terraqueos si haces eso )

Si tienes suerte y se acepta la PR Jesus incorporara los cambios en su rama develop, entonces tu puedes traerte esos nuevos cambios (fecth) incorporarlos en tu rama develop (merge) y eliminar la rama feature/my_nueva_rama (ya q los cambios ya estan en develop.

Ya q citas SourceTree te dire q es el yo utilizo y recomiendo si estais en MAC o Windows, para los linuxeros hay otro muy similar q ahora no recuerdo. Pero siempre recomiendo interface grafica, ya es bastante jodido esto como para encima tener q imaginarte los grafos-historial sin ayuda.

Joder, la verdad es que si que es un poco jaleo.
Yo lo que hago es:

- Me hago un fetch de develop de la rama de Jesus en mi github
- Hago los cambios
- Mergeo en MI github
- Solicito un PR a developer de Jesus...hasta que el mergea.

kampanita escribió:Joder, la verdad es que si que es un poco jaleo.
Yo lo que hago es:

- Me hago un fetch de develop de la rama de Jesus en mi github
- Hago los cambios
- Mergeo en MI github
- Solicito un PR a developer de Jesus...hasta que el mergea.

Entiendo q no creas la rama feature/my_nueva_rama. ¿no?
Como ya dije somos todos novatos en esto, pero...

• Entonces no puedes continuar desarrollando otras cosas paralelas a tu PR por q cualquier cambio en la rama se enviara automaticamente a la PR al subirlo a tu GITHUB (es importante diferenciar entre GIT -en local- y GITHUB -servidor remoto-) Con la utilizacion de la rama feature/my_nueva_rama bastaria con crear otra rama desde el mismo punto q esta (rama develop) y continuar alli los nuevos desarrollos.
• Tampoco podrias irte bajando los merges de Jesus vaya haciendo (nuevos canales o correcciones por ejemplo), ya q podrian entrar en conficto con tu PR. Con la utilizacion de la rama feature/my_nueva_rama los nuevos canales se bajan a la rama develop y aunq feature/my_nueva_rama no los tenga, no importa ya q develop si.
• Si Jesus, despues de un tiempo, desestima tu propuesta ¿como vuelves a tener tu rama develop como estaba? Si haces fetch de la de Jesus y la mergeas con la tuya (o pull q hace lo mismo en un solo paso), los cambios incluidos en tu PR no tienen por q desaparecer. Las ramas se mezclan, pero tu rama no tiene por q coincidir con la de Jesus y proximas PR llevaria de nuevo lo descartado de esta. Solo se me ocurre q podrias hacer reset, y despues de nuevo pull (pero va a ser un lio).
  Con la utilizacion de la rama feature/my_nueva_rama bastaria con eliminarla o dejarla ahi en el olvido, mi develop siempre sigue al de Jesus.

Parece un poco lio asi explicado pero una vez lo entiendes es sencillo. Y si quereis profundizar un poco mas buscar gitflow, q aunq a Jesus no le guste cada uno es su local es libre de usarlo (evidentemente yo lo uso...a veces)

por lo que por mi parte me toca:

• 1. develop-mediaserver: Si no me equivoco, tal como esta se puede mergear con develop sin conflictos, y todo debería funcionar correctamente...
  
  2. develop-limpieza-y-reorganización: dados los cambios que se han ido produciendo en los últimos commits, la incorporación del nuevo ítem.py, y que ya esta publicada la versión mediaserver, creo que la descartaría,por lo menos para usarla tal cual, se pueden ir cogiendo cosas de aquí y de allí, si interesa. Pero y ya iremos reestructurando el código poco a poco, que creo que generara menos problemas...
  
  3. Servertools dinámico: Tiene conflictos y los tendrá siempre... porque cada vez que se actualiza un canal o server se generan nuevos conflictos los he corregido muchas veces pero siempre llega un commit y se vuelven a generar, a mi no me cuesta nada resolverlos, ya que todo lo hago mediante unos scripts...
  
  • 1. genero los XML en función de la información actual del servertools.
    2. coloco el servertools.py modificado por mi en core (Recuerda que lo he movido de servers a core, ya que tiene mas sentido dejar la carpeta servers solo para servers)
    2. actualizo todos los "from servers import servertools" por "from core import servertools"
  
  
  todo lo hago automatizado así que es un momento, de manera que cuando tengas intención de mergearlo y tengas todos los commits mergeados para no generar conflictos, en ese momento me avisas y resuelvo los conflictos, así no tengo que estar corrigiéndolos tantas veces...

Pues por lo q me toca a mi:

• Creo q lo primero es dejar la rama Master quietecita no mergear nada de momento.
• Añadir a Develop (merge) la PR de la configuracion de canales (como ya se dijo en su dia). Ahora mismo no hay conflictos, pero si empezamos a mergear canales los habra. Ademas creo q hay varios desarrollos paralelos q estan esperando q se apruebe esto.
• Despues se pueden mergear las PR de canales modificados (siempre a DEVELOP) sino hay conflictos, y si los hay deberian ser sencillo de resolver.
• Continuariamos con el resto de PR (Servertools dinámico, infoLabels, Torrents, etc...) segun se vayan solucionando conflictos.
• Como bien dices creo de develop-mediaserver no tiene por q tener conflictos asi q la puedes mergear cuando quieras
• Para terminar, despues de unos dias probando la rama DEVELOP, se podria mergear con MASTER. Y si se quiere, actualizar el numero de version donde corresponda y lanzar nueva version (propongo la 4.1.0 y si ha correciones 4.1.1, 4.1.2, etc...)

Se q con este planteamiento hay canales corregidos q tardaran en llegar al usuario de a pie, pero si no se hace con un poco de orden luego aparecen cosas raras como por ejemplo los json q ya hemos borrado 2 o 3 veces y aun estan ahi