PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Бъдещето на Postgres-XL

Вероятно знаете, че Postgres-XL е разпределена база данни, базирана на PostgreSQL. Преди няколко дни пуснахме кода XL 9.6 в публичното git хранилище. Допълнителни подробности за новите неща, налични в Postgres-XL 9.6, са достъпни тук.

Темата на тази публикация в блога обаче е доста различна. Бих искал да обсъдя някои промени в практиките за управление и разработка на проекти и защо (и как) планираме да го променим.

На пръв поглед общността на XL може да не изглежда особено активна, особено ако погледнете само кода, броя на сътрудниците или трафика в пощенските списъци. Знаем, че това не е съвсем точно, тъй като получаваме голям интерес извън списъка от клиенти и разработчици, които създават вълнуващи неща на Postgres-XL. Но също така показва, че може би бихме могли да подобрим тази страна на проекта, за да улесним добавянето на код или предоставянето на обратна връзка.

Знаем също, че има доста Postgres-XL вилки. Не очакваме хората да спрат да работят върху тях и да се върнат към XL; някои форкове адресират случаи на употреба, които не са основната цел на XL. Но може би тези разклонения биха могли да се възползват от прехвърлянето на някои от общите подобрения (напр. корекции на грешки или някои от скучните инфраструктурни битове), намаляване на тежестта на поддръжката и намаляване на конфликтите при сливане.

Очевидно това е дългосрочна цел и няма едно конкретно нещо, което да я накара да се случи. Така че не се колебайте да предложите други промени или да посочите допълнителни неприятности, които ви пречат да допринесете за XL.

Разрастване на общността

Една от целите на тези промени е да разширят общността на XL и да я направят по-активна. Това включва не само получаване на повече съобщения в пощенските списъци, повече изтегляния, доклади за грешки (или какъвто и да е показател, който изберете). Имам предвид също споделяне на контрола върху проекта с по-широка общност, включително например предоставяне на права за ангажиране на опитни сътрудници и т.н.

Въпросът не е "ако", а "кога". Нямаме точен график или крайни срокове за добавяне на committers, но според мен това ще се случи рано или късно.

Дръжте XL близо до PostgreSQL

Една от причините, поради които не искаме да приемем по-пълна (и сложна) платформа за разработка, е, че искаме да поддържаме Postgres-XL възможно най-близо до PostgreSQL, както по отношение на кода, така и по отношение на практиките за разработка. А PostgreSQL използва много прост процес, базиран на изпращане на пачове до пощенски списък. Това е едновременно просто и също така служи като проста „одитна пътека“.

Така че не планираме да преместваме разработката към github или gitlab, но нищо не ви пречи да възприемете тези технологии, докато работите върху XL, стига окончателните пачове да бъдат изпратени до пощенския списък. Използваме github вътрешно, например.

Преместете се от Sourceforge

Преди много време sourceforge беше чудесно място за хостване на проекти с отворен код. Но в днешно време сайтът изглежда почти в режим само за поддръжка, изправен е пред различни противоречия, свързани с пакетирането на рекламен софтуер към изтегляния и т.н. Време е да продължим напред.

За щастие не ни трябва толкова много – уебсайт на проекта, git хранилище и няколко пощенски списъка и. Първите два елемента – уебсайтът и git хранилището вече се хостват извън sourceforge.

Така че трябва само да направим нещо с пощенските списъци, които лесно можем да хостваме на http://www.postgres-xl.org (и дори можем да импортираме текущите архиви, за да не загубим историята).

Планът е тази промяна да се направи някъде следващата седмица. Ако сте абонирани за някой от пощенските списъци, автоматично ще бъдете абонирани за новите пощенски списъци и ще получите съобщение с всички подробности. Основната промяна ще бъде промяна на домейна от @lists.sourceforge.net до @lists.postgres-xl.org .


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Записът, върнат от функцията, има конкатенирани колони

  2. ECONNREFUSED за Postgres на nodeJS с докери

  3. Разгръщане и конфигуриране на PostgreSQL с Puppet

  4. Сравнителни показатели за PostgreSQL Meltdown

  5. Как работи current_date в PostgreSQL