Re: Hackathon news - Mailing list pgsql-pkg-debian

Hello Christoph,

thanks for the report!

Christoph Berg [2012-09-06 13:33 +0200]:
> We need to:
>
>  1. get our own postgresql-common package with the right supported-versions script

We already discussed this briefly on IRC. This seems to be the only
delta required, which is both tiny as well as bothersome as it won't
ever go away. The difference between merging to new p-common releases
and just pulling them unmodified into pgapt is considerable, so I
think we should find a way to avoid this permanent delta.

As you already plan to have a separate package which provides the apt
pinning, could we not just use the same package to divert
postgresql-client-common's
/usr/share/postgresql-common/supported-versions script ? Or we change
supported-versions to check if a file or script
/usr/share/postgresql-common/supported-versions.local exists and
return its contents/run it and return its output?

> ### distributions and release policy
>
> We publish maintained PostgreSQL versions to current debian and ubuntu
> releases. We also publish old PostgreSQL versions to current and old debian
> and ubuntu versions.

Do you plan to include running the p-common test suite in Jenkins, to
ensure that there are no mis-builds or other things we haven't thought
of (e. g. a p-common operation that does not work with 8.3)?

> Several sources are available for the packaging. We can either build from
> the current `apt-get source` packaging found in sid or from the source code
> repository on `alioth` (svn and git are in use over there).

The Debian PostgreSQL packages are in bzr. But I'd advise to only
build from released versions. To avoid having to wait for the Debian
archive processing, how about building packages from tags only,
instead of from arbitrary revisions? Then jenkins could watch out for
new tags, and immediately get going when it sees one, instead of
having to wait for half a day for the Debian archive publisher.

> One idea is to build *testing* packages from their source code repositories
> and *production* package directely from the `sid` distribution. That means
> we're doing both Quality Assurance and Backports, but that might be a little
> too much for the first version of this build system.

The testing one is interesting if we could combine it with p-common
test suite runs (but that should happen for production packages as
well). But yes, it's a matter of extra hardware resources.

> ## publishing policy
>
> Generally we want to only include packages that come from Debian unstable,
> usually in the version from there. Exceptions should be rare so we don't run
> out of sync and lose track.

Don't you also want to track experimental? That's where I put all the
betas and RCs, as well as 9.2 right now while we are in release
freeze.

Thanks!

Martin

--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)