[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is Sid for broken stuff? Is it too much to ask for testing the packages?



On Thu, Dec 12, 2002 at 01:08:37AM +0100, Marek Habersack wrote:

> Going back to postgres - apparently the maintainer "has no time" to
> test upgrades from earlier formats of the database to the latest
> format. If the upgrade isn't tested by the maintainer and isn't tested
> now - when is it going to be tested and on whose data?  Ours? 

yes.  the maintainer relies on other developers & bleeding edge users to
test their package - no maintainer can test every possible case.
postgres is a particularly difficult package to test upgrades on because
there have been so many previous versions where db incompatibilities
require the data to be exported & re-imported.

personally, i think Oliver is doing a first-class job in his
maintainence of the postgres packages.  there wouldn't BE any kind of
automatic upgrade for postgres if it wasn't for the work that he has
done...you'd be left with the job of doing a manual conversion every
time.


> Our users's in 6 months when a broken package hits stable? 

anyone running postgres (or other db package) on a production server
would be crazy not to have the same version installed on a workstation
or test machine just so that they can test that the upgrade works
*before* applying it to their production server.  this is necessary
whether they run stable or testing or unstable.

a packaging system like dpkg is a great tool, but it's not a subsitute
for common sense, nor is it a substitute for safe change management
procedures.

i run debian unstable on all my machines, including production servers.
i manage to do this safely by testing all upgrades on my least important
machines (workstations, development/test boxes, secondary/backup
servers) first.  this lets me know whether unstable is in a usable state
on any given day (most days it is, some days it is not), and it also
gives me a chance to have a practice run of the upgrade before i risk my
production servers.  

if there are no problems, then my production servers get upgraded.  if
there are only a few minor & easily fixable problems, i may still risk
upgrading them.  if there are major problems then i don't upgrade them.

this is called "common sense".  it's not rocket-science, it's not
difficult, it's just a natural result of having a brain and being
willing to use it.

if you want to run unstable, that's the safe way to do it.  

there are risks associated with running unstable, if you're not willing
or not able to deal with those risks then DON'T RUN UNSTABLE.  simple as
that. if you do take the risk and something breaks, then don't whine
about it - be part of the solution and help to fix it.


> At least last 3 Debian releases of the postgresql packages were broken
> - the database format upgrade from 7.2 to 7.3 seems to be broken
> upstream, is it too much

it worked for me.  there were a few hassles with the postinst script
(something weird with the way it parses the pg_hba.conf file - i suspect
that the mistake i made was to say "Y" when dpkg asked if i wanted to
replace pg_hba.conf), but once i sorted that out the upgrade worked.

i'll run through it a few more times on other workstations and
development boxes (where i have postgres 7.2 installed) before i trust
the upgrade enough to run on any of my production database servers.

that'll also give me enough information about any problems that i can
submit a useful bug report rather than just a vague "i had a few minor
problems but i can't describe them properly".

craig

-- 
craig sanders <cas@taz.net.au>

Fabricati Diem, PVNC.
 -- motto of the Ankh-Morpork City Watch



Reply to: