sql >> Database teknologi >  >> RDS >> PostgreSQL

Fremtiden for Postgres-XL

Du ved sikkert, at Postgres-XL er en distribueret database baseret på PostgreSQL. For et par dage siden skubbede vi XL 9.6-koden ind i det offentlige git-lager. Yderligere detaljer om de nye ting, der er tilgængelige i Postgres-XL 9.6, er tilgængelige her.

Emnet for dette blogindlæg er dog et helt andet. Jeg vil gerne diskutere nogle ændringer af projektledelse og udviklingspraksis, og hvorfor (og hvordan) vi planlægger at justere det.

Ved første øjekast virker XL-fællesskabet måske ikke særligt aktivt, især hvis du kun ser på koden for antallet af bidragydere eller trafikken på mailinglister. Vi ved, at dette ikke er helt præcist, da vi får en masse off-liste interesse fra kunder og udviklere, der bygger spændende ting på Postgres-XL. Men det viser også, at vi måske kunne forbedre denne side af projektet for at gøre det nemmere at bidrage med kode eller give feedback.

Vi ved også, at der er en del Postgres-XL gafler. Vi forventer ikke, at folk holder op med at arbejde på dem og flytter tilbage til XL; nogle gafler adresserer brugstilfælde, der ikke er det primære formål med XL. Men måske kan disse gafler drage fordel af at upstreame nogle af de generiske forbedringer (f.eks. fejlrettelser eller nogle af de kedelige infrastrukturbits), sænke vedligeholdelsesbyrden og reducere flettekonflikter.

Det er klart, at dette er et langsigtet mål, og der er ikke én bestemt ting, der ville få det til at ske. Så du er velkommen til at foreslå andre ændringer eller påpege yderligere irritationsmomenter, der afholder dig fra at bidrage til XL.

Udvidelse af fællesskabet

Et af målene med disse ændringer er at udvide XL-fællesskabet og gøre det mere aktivt. Det inkluderer ikke kun at få flere beskeder på mailinglisterne, flere downloads, fejlrapporter (eller hvad du nu vælger). Jeg mener også at dele kontrollen over projektet med et bredere fællesskab, herunder for eksempel at give forpligtelsesrettigheder til erfarne bidragydere osv.

Det er ikke et spørgsmål om "hvis", men "hvornår". Vi har ikke en nøjagtig tidsplan eller deadlines for tilføjelse af committers, men mit skøn er, at det vil ske før snarere end senere.

Hold XL tæt på PostgreSQL

En af grundene til, at vi ikke ønsker at adoptere en mere komplet (og kompleks) udviklingsplatform er, at vi ønsker at holde Postgres-XL så tæt på PostgreSQL som muligt, både hvad angår kode og udviklingspraksis. Og PostgreSQL bruger en meget enkel proces, baseret på at sende patches til en mailingliste. Det er både enkelt og fungerer også som et simpelt "revisionsspor."

Så vi planlægger ikke at flytte udviklingen til github eller gitlab, men der er intet, der forhindrer dig i at omfavne disse teknologier, mens du arbejder på XL, så længe de sidste patches bliver sendt til mailinglisten. Vi bruger for eksempel github internt.

Flyt fra Sourceforge

For længe siden var sourceforge et fantastisk sted at være vært for open source-projekter. Men i dag virker webstedet stort set kun i vedligeholdelsestilstand, stod over for forskellige kontroverser i forbindelse med bundtning af adware til downloads osv. Det er tid til at komme videre.

Heldigvis har vi ikke brug for så meget - et projektwebsted, et git-lager og et par mailinglister og. De første to elementer – hjemmesiden og git-lageret er allerede hostet fra sourceforge.

Så vi skal kun gøre noget ved mailinglisterne, som vi nemt kan hoste på http://www.postgres-xl.org (og vi kan endda importere de nuværende arkiver, så vi ikke mister historikken).

Planen er at lave denne ændring engang i næste uge. Hvis du abonnerer på en af ​​mailinglisterne, bliver du automatisk tilmeldt de nye mailinglister, og du vil modtage en besked med alle detaljerne. Hovedændringen vil være en ændring af domænet fra @lists.sourceforge.net til @lists.postgres-xl.org .


  1. Hvor dyre er implicitte konverteringer på kolonnesiden?

  2. Sådan tilføjer du lodrette grænser til dit SQL*Plus / SQLcl-outputgitter

  3. Kald en sæt-returnerende funktion med et array-argument flere gange

  4. Mysql event fejl ved hjælp af php