You probably know that Postgres-XL is a distributed database based on PostgreSQL. A few days ago we pushed the XL 9.6 code into the public git repository. Additional details about the new stuff available in Postgres-XL 9.6 are available here.
The topic of this blog post is quite different, though. I’d like to discuss some changes to the project management and development practices, and why (and how) we plan to tweak it.
At first sight, the XL community may not seem particularly active, particularly if you only look at code the number of contributors or traffic on mailing lists. We know this is not entirely accurate, as we get a lot of off-list interest from customer and developers building exciting stuff on Postgres-XL. But it also shows that perhaps we could improve this side of the project, to make it easier to contribute code or provide feedback.
We also know there are quite a few Postgres-XL forks. We don’t expect people to stop working on them and move back to XL; some forks address use cases that are not the primary aim of XL. But perhaps those forks might benefit from upstreaming some of the generic improvements (e.g. bugfixes or some of the boring infrastructure bits), lowering the maintenance burden and reducing merge conflicts.
Obviously, this is a long term goal and there is not one particular thing that would make it happen. So feel free to propose other changes, or point out additional annoyances that keep you from contributing to XL.
Growing the community
One of the goals of these changes is to growing the XL community and making it more active. That includes not only getting more messages on the mailing lists, more downloads, bug reports (or whatever is metric you pick). I also means sharing control of the project with a wider community, including for example granting commit rights to experienced contributors, etc.
It’s not a question of “if” but “when.” We don’t have an exact schedule or deadlines for adding committers, but my estimate is that it’ll happen sooner rather than later.
Keep XL close to PostgreSQL
One of the reasons why we don’t want to adopt a more complete (and complex) development platform is that we want to keep Postgres-XL as close to PostgreSQL as possible, both in terms of code and development practices. And PostgreSQL uses a very simple process, based on sending patches to a mailing list. That is both simple and also serves as a simple “audit trail.”
So we do not plan to move the development to github or gitlab, but there’s nothing preventing you from embracing those technologies while working on XL, as long as the final patches get sent to the mailing list. We’re using github internally, for example.
Move off Sourceforge
Long time ago, sourceforge was a great place to host open source projects. But nowadays the site seems pretty much in maintenance-only mode, faced various controversies related to bundling adware to downloads, etc. It’s time to move on.
Luckily, we don’t need that much – a project website, a git repository and a few mailing lists and. The first two items – website and the git repository are already hosted off sourceforge.
So we only need to do something about the mailing lists, which we can easily host on http://www.postgres-xl.org (and we can even import the current archives, so that we don’t lose the history).
The plan is to do this change sometime next week. If you’re subscribed to any of the mailing lists, you’ll be automatically subscribed to the new mailing lists, and you’ll receive message with all the details. The main change will be a change of the domain, from @lists.sourceforge.net to @lists.postgres-xl.org.