Probabilmente sai che Postgres-XL è un database distribuito basato su PostgreSQL. Alcuni giorni fa abbiamo inserito il codice XL 9.6 nel repository git pubblico. Ulteriori dettagli sulle novità disponibili in Postgres-XL 9.6 sono disponibili qui.
L'argomento di questo post sul blog è piuttosto diverso, però. Vorrei discutere alcune modifiche alla gestione del progetto e alle pratiche di sviluppo e perché (e come) prevediamo di modificarle.
A prima vista, la comunità XL potrebbe non sembrare particolarmente attiva, in particolare se si guarda al codice solo al numero di contributori o al traffico sulle mailing list. Sappiamo che questo non è del tutto accurato, poiché riceviamo molto interesse fuori lista da parte di clienti e sviluppatori che creano cose interessanti su Postgres-XL. Ma mostra anche che forse potremmo migliorare questo lato del progetto, per rendere più facile contribuire con codice o fornire feedback.
Sappiamo anche che ci sono un bel po' di fork Postgres-XL. Non ci aspettiamo che le persone smettano di lavorarci su e tornino a XL; alcuni fork affrontano casi d'uso che non sono l'obiettivo principale di XL. Ma forse quei fork potrebbero trarre vantaggio dall'upstreaming di alcuni dei miglioramenti generici (ad es. correzioni di bug o alcuni dei noiosi bit dell'infrastruttura), riducendo il carico di manutenzione e riducendo i conflitti di fusione.
Ovviamente, questo è un obiettivo a lungo termine e non c'è una cosa in particolare che possa realizzarlo. Quindi sentiti libero di proporre altre modifiche o segnalare ulteriori fastidi che ti impediscono di contribuire a XL.
Crescere la comunità
Uno degli obiettivi di questi cambiamenti è far crescere la comunità XL e renderla più attiva. Ciò include non solo ricevere più messaggi nelle mailing list, più download, segnalazioni di bug (o qualsiasi altra metrica tu scelga). Intendo anche condividere il controllo del progetto con una comunità più ampia, inclusa, ad esempio, la concessione di diritti di impegno a contributori esperti, ecc.
Non è una questione di “se” ma di “quando”. Non abbiamo un programma preciso o scadenze per l'aggiunta di committenti, ma la mia stima è che accadrà prima piuttosto che dopo.
Mantieni XL vicino a PostgreSQL
Uno dei motivi per cui non vogliamo adottare una piattaforma di sviluppo più completa (e complessa) è che vogliamo mantenere Postgres-XL il più vicino possibile a PostgreSQL, sia in termini di codice che di pratiche di sviluppo. E PostgreSQL utilizza un processo molto semplice, basato sull'invio di patch a una mailing list. Questo è allo stesso tempo semplice e funge anche da semplice "traccia di controllo".
Quindi non prevediamo di spostare lo sviluppo su github o gitlab, ma non c'è nulla che ti impedisca di abbracciare queste tecnologie mentre lavori su XL, a patto che le patch finali vengano inviate alla mailing list. Ad esempio, utilizziamo github internamente.
Esci da Sourceforge
Molto tempo fa, sourceforge era un ottimo posto per ospitare progetti open source. Ma al giorno d'oggi il sito sembra praticamente in modalità di sola manutenzione, ha dovuto affrontare varie controversie relative al raggruppamento di adware per i download, ecc. È ora di andare avanti.
Fortunatamente, non abbiamo bisogno di molto:un sito Web del progetto, un repository git e alcune mailing list e. I primi due elementi:il sito Web e il repository git sono già ospitati fuori da sourceforge.
Quindi dobbiamo solo fare qualcosa per le mailing list, che possiamo ospitare facilmente su http://www.postgres-xl.org (e possiamo anche importare gli archivi attuali, in modo da non perdere la cronologia).
Il piano è di fare questo cambiamento la prossima settimana. Se sei iscritto a una qualsiasi delle mailing list, verrai automaticamente iscritto alle nuove mailing list e riceverai un messaggio con tutti i dettagli. La modifica principale sarà una modifica del dominio, da @lists.sourceforge.net a @lists.postgres-xl.org .
