edición general
18 meneos
105 clics
KDE migra toda su base de código a GitLab [ENG]

KDE migra toda su base de código a GitLab [ENG]

Después de nuestra decisión final a adoptar GitLab en noviembre de 2019, KDE comenzó el trabajo de hacer frente a los muchos desafíos que aparecen al migrar toda una plataforma de desarrollo de una comunidad de código abierto tan grande. KDE ha completado oficialmente la primera fase de la migración y los colaboradores han comenzado a utilizar GitLab en su día a día.

| etiquetas: kde , plasma , migración , base de código , gitlab , git
  1. Relacionada: KDE migra a GitLab, “una infraestructura amigable y fácil de usar” (la noticia enlazada es en la que se toma la decisión, la actualmente enviada es la que indica que se ha completado la primera fase y que los desarrolladores ya están usando GitLab en el día a día).
  2. En esta época ya no importa si sale KDE 5 o GNOME 4...
  3. #2 No sé, creo que sí, y sobre todo por el asunto de systemd
  4. #3 Era un troleo antológico.
  5. ¿Al final cambia el nombre a plasma, se queda en kde o ambas cosas?
  6. #4 Disculpe, no lo entendí así.
  7. #7 Yo no lo veo así. De hecho creo que la rivalidad entre KDE y Gnome le ha hecho más bien que mal al escritorio de Linux (a pesar del enorme éxito obtenido en el sector :troll: ).

    En un proyecto de estas características, aunque obviamente necesita una comunidad sólida que lo sustente, suelen pesar más las decisiones estratégicas que la fuerza bruta. Si no que se lo digan a Gnome, que publicó Gnome 3 y le salieron más forks que a Juancar :-D
  8. ¿Desde dónde migran a gitlab?
  9. #2 jaja, que grande. Echaba de menos ese troleo, lo podías haber pegado entero ostias.
  10. #5 KDE es la comunidad y Plasma el escritorio. Internamente lo llaman Plasma, pero entre la costumbre herededada de escritorios anteriores y el gusto de KDE por anteponer sus siglas a buena parte de sus productos, veo difícil que la gente deje de llamarlo "KDE Plasma" y pase a llamarlo simplmemente "Plasma".

    Supongo que le acabará pasando como a Apple, que le quiso quitar el "mac" a Mac OS X... y acabó claudicando y quitándole la "X" :-D
  11. #9 Habían cambiado Review Board por Phabricator hace nada y ahora migran a GitLab CE. Pero es que más que comprensible, GitLab no tiene rival. Ni en prestaciones, ni en consumo. Que come más que un alcalde nuevo :-D

    Lo que sí que no he visto es si han dicho que harán con la CI, si integrarán Jenkins en GitLab (que le va como un guante), migrarán a GitLab CI, irán hacia un modelo mixto...

    La verdad es que es una gran noticia que una comunidad con el compromiso de KDE se involucre en un proyecto como GitLab CE. Tanto por los aportes que hará al código como por ejercer de contrapeso con algunas practiquillas cuestionables (léase con voz de Flanders) en las que GitLab Inc. cae de vez en cuando.
  12. El problema de kde va a ser cómo gestionan el futuro qt6, los trollers no darán soporte a los LTS. Veremos como afecta al mantenimiento de plasma. Un fork de qt podría ser posible.
  13. #12 Tanto como hace nada... Phabricator se estaba usando desde 2015
  14. #14 ¿Qué dices? :-O Con razón tengo yo estas canas en la barba...
  15. #14 Bueno, en 2019 aún tiraban de "rbt" para alguna cosa. Ya me estabas asustando, que sólo son unas canitas... :-D
  16. #4 Un troleo añejo, criado en barrica barrapuntera durante lustros.
  17. #12 GitLab tiene su propio CI/CD, que creo que es más limitado que Jenkins (o al menos tendrá menos plugins) pero más moderno en su concepción. No sé qué usará KDE, si se pasará el de GitLab o usarán Jenkins.
  18. #13 Aquello fue una amenaza, pero hasta donde yo sé aún no han hecho nada al respecto, de momento nada ha cambiado. Veremos qué pasa, pero si hacen eso habrá fork, seguro.
  19. #19 No, no es una amenaza. Es bien real. Qt6 va a ser así. QtCompany solo dejará públicos los parches en mainline, y los parches para los LTS solo se los darán a los clientes que hayan pagado la licencia comercial. Supongo que la comunidad si no quiere forkear debería al menos crear un repositorio con los LTS y hacer backport de los parches, o sea, lo mismo que ya ha hecho QtCompany.
    La verdad es que el fork hace tiempo que se debería haber hecho, aunque es una putada bastante grande, porque perdemos todos.
  20. #17 Echo de menos BP, Bilo y Nano y todas esas webs. Siguen Libertonia y algunos grupos esp.* más muertos que otra cosa.

    En el mundo de fuera, existen BBS', Gopher, News, y hasta redes Fido con bastantes mas usuarios.
  21. #20 En el reddit de KDE se comentó el asunto hace 2 meses y el resumen es ese, que Qt dijo lo que dijo pero aún no es efectivo. Habrá que esperar a ver si lo cumplen o no.

    www.reddit.com/r/kde/comments/fx5q8j/qt_open_source_and_corona/
  22. #21 Grandes tiempos de una internet naciente y virgen, poblada por los pioneros. En aquellos tiempos se pensaba que iba a traer la razón, la ciencia y la iluminación al mundo, y al final resultó que potenció todo lo contrario.

    Pero fue bonito vivirlo.

    :foreveralone:
  23. #23 www.cyberiada.org/r34.htm ahí abajo aún quedan 4 BBS en castellano mas o menos.

    telnet a bbs.zruspas.org y bueno, seguro que seas o bien el mantenedor o conocido :-P
  24. #22 KDE puede hacer un fork si eso pasa.
  25. #22 www.qt.io/blog/qt-offering-changes-2020
    Veremos si cumplen o no. Esta historia empieza con qt5.15
  26. #8 Si KDE no hubiera elegido un toolkit que desarrolla una compañía comercial ahora no tendrían estos problemas. GNOME sólo surgió por este hecho.
  27. #12 por si te interesa ampliar información, algunas de tus dudas las resuelven en la issue en la que se lleva la migración: gitlab.com/gitlab-org/gitlab/-/issues/24900

    En principio no integrarán GitLab con Jenkins, porque el plugin de GitLab para Jenkins es solo de la versión EE, y KDE no utiliza componentes no libres (lo comenta Ben Cooksley en ese hilo).
  28. #2 el troll de la milanesa xD como me he reido con el
  29. #27 Ése fue uno de los motivos, pero poco después de iniciarse el proyecto GNOME, KDE firmó un acuerdo los trolls que les permitía publicar Qt con licencia BSD si ellos dejaban de publicar la licencia gratuita y no mucho después se liberó Qt.

    Si ése hubiese sido el único motivo habrían colaborado con Harmony, que era un proyecto para publicar una libería compatible con Qt con licencia GPL y que se cerró cuando Trolltech liberó Qt.

    En realidad, Icaza y compañía tenían otras muchas ideas para implementar en su escritorio, principalmente el modelo de componentes. De hecho GNOME viene de GNU Network Object Model Environment. Aunque finalmente, como mandan los cánones, dejó de ser unas siglas (la otra opción era convertirlo en un acrónimo recursivo :-D )

    Pero en todo caso yo no lo veo como "problemas". KDE y GNOME tienen filosofías muy diferentes y es fantástico contar con dos entornos de ese nivel en Linux. Hay un meme recurrente sobre un presunto superescritorio que saldría de la labor conjunta de los equipos de KDE y GNOME, pero el desarrollo de un proyecto de esta magnitud es una cuestión mucho más cualitativa que cuantitavia.

    Yo creo que si no hubiese nacido GNOME cuando lo hizo probablemente hoy sólo tendríamos un KDE peor que el actual y una pléyade de forks nacidos con la publicación de KDE 4, el primer levantamiento popular contra un desktop. Ahora eso ya es una moda, si a un desktop no se le revela la comunidad en cada release es que es un desktop regulero :-D
comentarios cerrados

menéame