Du vet förmodligen att Postgres-XL är en distribuerad databas baserad på PostgreSQL. För några dagar sedan tryckte vi in XL 9.6-koden i det offentliga git-förrådet. Ytterligare information om de nya sakerna i Postgres-XL 9.6 finns tillgängliga här.
Ämnet för det här blogginlägget är dock ett helt annat. Jag skulle vilja diskutera några förändringar av projektledning och utvecklingsmetoder, och varför (och hur) vi planerar att justera det.
Vid första anblicken kanske XL-communityt inte verkar särskilt aktivt, särskilt om du bara tittar på koden för antalet bidragsgivare eller trafiken på e-postlistor. Vi vet att detta inte är helt korrekt, eftersom vi får mycket intresse från kunder och utvecklare som bygger spännande saker på Postgres-XL. Men det visar också att vi kanske skulle kunna förbättra den här sidan av projektet, för att göra det lättare att bidra med kod eller ge feedback.
Vi vet också att det finns en hel del Postgres-XL gafflar. Vi förväntar oss inte att folk slutar arbeta med dem och flyttar tillbaka till XL; vissa gafflar adresserar användningsfall som inte är det primära syftet med XL. Men kanske dessa gafflar kan dra nytta av att uppströmma några av de generiska förbättringarna (t.ex. buggfixar eller några av de tråkiga infrastrukturbitarna), minska underhållsbördan och minska sammanslagningskonflikter.
Uppenbarligen är detta ett långsiktigt mål och det finns inte en speciell sak som skulle få det att hända. Så kom gärna med förslag på andra ändringar eller påpeka ytterligare irritationsmoment som hindrar dig från att bidra till XL.
Utveckla gemenskapen
Ett av målen med dessa förändringar är att utöka XL-gemenskapen och göra den mer aktiv. Det inkluderar inte bara att få fler meddelanden på e-postlistorna, fler nedladdningar, felrapporter (eller vad du än väljer). Jag menar också att dela kontrollen över projektet med en bredare gemenskap, inklusive till exempel att ge erfarna bidragsgivare rättigheter att åta sig, etc.
Det är inte en fråga om "om" utan "när". Vi har inget exakt schema eller deadlines för att lägga till committers, men min uppskattning är att det kommer att ske förr snarare än senare.
Håll XL nära PostgreSQL
En av anledningarna till att vi inte vill anta en mer komplett (och komplex) utvecklingsplattform är att vi vill hålla Postgres-XL så nära PostgreSQL som möjligt, både när det gäller kod och utvecklingsmetoder. Och PostgreSQL använder en mycket enkel process, baserad på att skicka patchar till en e-postlista. Det är både enkelt och fungerar också som ett enkelt "revisionsspår."
Så vi planerar inte att flytta utvecklingen till github eller gitlab, men det finns inget som hindrar dig från att omfamna dessa teknologier medan du arbetar på XL, så länge de sista patcharna skickas till e-postlistan. Vi använder github internt, till exempel.
Flytta bort Sourceforge
För länge sedan var sourceforge ett bra ställe att vara värd för projekt med öppen källkod. Men nuförtiden verkar sajten i stort sett vara i enbart underhållsläge, stod inför olika kontroverser relaterade till buntning av adware till nedladdningar, etc. Det är dags att gå vidare.
Lyckligtvis behöver vi inte så mycket - en projektwebbplats, ett git-förråd och några e-postlistor och. De två första objekten – webbplats och git-förvaret finns redan på sourceforge.
Så vi behöver bara göra något åt e-postlistorna, som vi enkelt kan ha på http://www.postgres-xl.org (och vi kan till och med importera de aktuella arkiven, så att vi inte förlorar historiken).
Planen är att göra denna förändring någon gång nästa vecka. Om du prenumererar på någon av e-postlistorna kommer du automatiskt att prenumerera på de nya e-postlistorna och du får ett meddelande med alla detaljer. Huvudändringen kommer att vara en ändring av domänen, från @lists.sourceforge.net till @lists.postgres-xl.org .