Probablemente sepa que Postgres-XL es una base de datos distribuida basada en PostgreSQL. Hace unos días, insertamos el código XL 9.6 en el repositorio público de git. Los detalles adicionales sobre las novedades disponibles en Postgres-XL 9.6 están disponibles aquí.
Sin embargo, el tema de esta publicación de blog es bastante diferente. Me gustaría analizar algunos cambios en las prácticas de gestión y desarrollo de proyectos, y por qué (y cómo) planeamos modificarlo.
A primera vista, la comunidad XL puede no parecer particularmente activa, especialmente si solo observa el código, el número de colaboradores o el tráfico en las listas de correo. Sabemos que esto no es del todo exacto, ya que recibimos mucho interés fuera de la lista de clientes y desarrolladores que crean cosas interesantes en Postgres-XL. Pero también muestra que tal vez podríamos mejorar este lado del proyecto, para que sea más fácil contribuir con el código o proporcionar comentarios.
También sabemos que hay bastantes horquillas Postgres-XL. No esperamos que la gente deje de trabajar en ellos y vuelva a XL; algunas bifurcaciones abordan casos de uso que no son el objetivo principal de XL. Pero tal vez esas bifurcaciones podrían beneficiarse de la actualización de algunas de las mejoras genéricas (por ejemplo, correcciones de errores o algunos de los bits de infraestructura aburridos), reduciendo la carga de mantenimiento y reduciendo los conflictos de fusión.
Obviamente, este es un objetivo a largo plazo y no hay nada en particular que lo haga posible. Así que no dude en proponer otros cambios o señalar molestias adicionales que le impiden contribuir a XL.
Hacer crecer la comunidad
Uno de los objetivos de estos cambios es hacer crecer la comunidad XL y hacerla más activa. Eso incluye no solo obtener más mensajes en las listas de correo, más descargas, informes de errores (o cualquier métrica que elija). También me refiero a compartir el control del proyecto con una comunidad más amplia, lo que incluye, por ejemplo, otorgar derechos de confirmación a colaboradores experimentados, etc.
No es una cuestión de “si” sino de “cuándo”. No tenemos un cronograma exacto o fechas límite para agregar confirmadores, pero mi estimación es que sucederá más temprano que tarde.
Mantenga XL cerca de PostgreSQL
Una de las razones por las que no queremos adoptar una plataforma de desarrollo más completa (y compleja) es que queremos mantener Postgres-XL lo más cerca posible de PostgreSQL, tanto en términos de código como de prácticas de desarrollo. Y PostgreSQL utiliza un proceso muy simple, basado en el envío de parches a una lista de correo. Eso es simple y también sirve como un simple "pista de auditoría".
Por lo tanto, no planeamos mover el desarrollo a github o gitlab, pero no hay nada que le impida adoptar esas tecnologías mientras trabaja en XL, siempre que los parches finales se envíen a la lista de correo. Estamos usando github internamente, por ejemplo.
Salir de Sourceforge
Hace mucho tiempo, sourceforge era un excelente lugar para albergar proyectos de código abierto. Pero hoy en día, el sitio parece estar en modo de solo mantenimiento, enfrentó varias controversias relacionadas con la agrupación de adware para descargas, etc. Es hora de seguir adelante.
Afortunadamente, no necesitamos tanto:un sitio web del proyecto, un repositorio git y algunas listas de correo y. Los dos primeros elementos:el sitio web y el repositorio git ya están alojados fuera de sourceforge.
Así que solo tenemos que hacer algo con las listas de correo, que podemos alojar fácilmente en http://www.postgres-xl.org (e incluso podemos importar los archivos actuales, para no perder el historial).
El plan es hacer este cambio en algún momento de la próxima semana. Si está suscrito a alguna de las listas de correo, se suscribirá automáticamente a las nuevas listas de correo y recibirá un mensaje con todos los detalles. El cambio principal será un cambio de dominio, de @lists.sourceforge.net a @lists.postgres-xl.org .
