Postgres major version support policy on Debian

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: pkg-postgresql-public(at)lists(dot)alioth(dot)debian(dot)org
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Postgres major version support policy on Debian
Date: 2008-10-02 10:49:04
Message-ID: 48E4A720.9000603@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

first of all: thanks for packaging Postgres for Debian. I'm willing to
help with that.

Unfortunately we are stuck with several Postgres 8.2 installations from
etch backports, which are no longer maintained by the backports, because
only 8.2 got dropped from testing.

I'm providing upgraded packages for Postgres 8.2 on my own website [1].
There are certainly other people who have run into the same issue, see
for example [2] who dislikes using Postgres backports for exactly that
reason.

Upgrading via pg_upgradecluster is definitely not an option due to
custom build extensions and because of the downtime involved.

On the backports-users mailing list I've requested that Postgres 8.2
gets re-added to etch-backports, with upgraded packages. So that
existing installations can get bug- and security fixes for that Postgres
versions. One argument for rejection [3] has been, that Postgres 8.2 is
not in testing anymore and can thus not be backported. I'm arguing that
Postgres 8.2 is a backport per se. Not from testing, but a backport of
newer software to etch.

Anyway, I'd like to reach an agreement on a decent policy about Postgres
major version support especially WRT the backports. I see these options:

* Postgres major versions that once got included should continue to be
supported and updated within the standard Debian infrastructure as long
as supported by the Postgres project itself.

* Postgres major versions dumped from testing, but once added to any
backport should be maintained on backports even if it gets dumped from
testing.

* Never include Postgres major versions from testing in the backports,
as those might get dumped from testing thus support cannot be guaranteed
anymore. (Except perhaps when we can be very sure that this won't happen).

Looking at it that way, I'm favoring the first option. However, I'd be
fine with the second as well. The third would be a pity, but still
better than status quo (because backports currently makes false promises
about maintenance of backported Postgtres major versions, IMO).

As already mentioned, I'm offering help in maintaining these packages.
I'm somewhat experienced in Debian packaging, but not familiar with
uploading or maintaining "official" packages (keen to learn, though).

Regards

Markus Wanner

[1]: announcement of my Postgres 8.2 backports:
http://lists.backports.org/lurker-bpo/message/20080923.161529.60f37f97.en.html

[2]: newish complaint on the postgres performance mailing list:
http://archives.postgresql.org/message-id/48E48822.5060009@usit.uio.no

[3]: backport policy argument, see also rest of the thread
http://archives.postgresql.org/message-id/48DA73E4.7060505@gmx.net

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Terry Lee Tucker 2008-10-02 10:52:07 Re: Trigger disable for table
Previous Message Reg Me Please 2008-10-02 10:31:47 Re: Transactions within a function body