#Postgresql git repository Patch

However, if it just means that “untli then it was just a patch living on the mailinglists” then it’s obviously fine - the part that’s potentially bad is if there is an internal, non-public, git-repo where development was done. If so, I suggest that’s the first thing you should change. That sounds like the development did not happen in public, but instead dropped as a batch of commits once already done.

#Postgresql git repository code

I’m not sure if I am misreading this, as I’m not following XL closely, so if I am then ignore the comment 🙂 But this:Ī few days ago we pushed the XL 9.6 code into the public git repository

The main change will be a change of the domain, from to all sounds like very good directions! A small tip, though.

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 plan is to do this change sometime next week.

So we only need to do something about the mailing lists, which we can easily host on (and we can even import the current archives, so that we don’t lose the history). The first two items – website and the git repository are already hosted off sourceforge. Luckily, we don’t need that much – a project website, a git repository and a few mailing lists and. But nowadays the site seems pretty much in maintenance-only mode, faced various controversies related to bundling adware to downloads, etc. Long time ago, sourceforge was a great place to host open source projects. We’re using github internally, for example. 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. That is both simple and also serves as a simple “audit trail.” And PostgreSQL uses a very simple process, based on sending patches to a mailing list. 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. 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. I also means sharing control of the project with a wider community, including for example granting commit rights to experienced contributors, etc. That includes not only getting more messages on the mailing lists, more downloads, bug reports (or whatever is metric you pick). One of the goals of these changes is to growing the XL community and making it more active.

#Postgresql git repository free

So feel free to propose other changes, or point out additional annoyances that keep you from contributing to XL. Obviously, this is a long term goal and there is not one particular thing that would make it happen. bugfixes or some of the boring infrastructure bits), lowering the maintenance burden and reducing merge conflicts. But perhaps those forks might benefit from upstreaming some of the generic improvements (e.g. 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. We also know there are quite a few Postgres-XL forks. 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 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. I’d like to discuss some changes to the project management and development practices, and why (and how) we plan to tweak it.Īt 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. The topic of this blog post is quite different, though. Additional details about the new stuff available in Postgres-XL 9.6 are available here. A few days ago we pushed the XL 9.6 code into the public git repository. You probably know that Postgres-XL is a distributed database based on PostgreSQL.

PostgreSQL 9 Cookbook – Chinese Edition.

PostgreSQL Server Programming Cookbook – 2nd Edition.

PostgreSQL 9 Administration Cookbook – 3rd Edition.

PostgreSQL High Availability Cookbook – 2nd Edition.