Re: Time to retire Windows XP buildfarm host?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time to retire Windows XP buildfarm host?
Date: 2016-12-05 17:06:23
Message-ID: CA+TgmoZtn=kp2hnZJDxOwgc_Uz8i2EEz_WMmQkRQsuwn7ozCVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 5, 2016 at 11:46 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I think it might be good to introduce a general formal policy of
> de-supporting platforms a year or three after their OS support
> ended.

I agree. If possible, I'd like it to be more like 3 years than 1 year
but that may not be possible in all cases without an unreasonable
amount of work. Since PostgreSQL is a database [citation needed], and
since upgrading to a new database version can be a pretty involved
procedure in some environments, it's a lot better for users if we
don't deprecate things sooner than is really necessary. On the other
hand, it's become clear - at least to me - that supporting systems
that don't really exist in the wild any more can be a real pain.

pademelon is a good example. I don't mind keeping that working if Tom
is willing to maintain it, but here's the thing: if a certain
portability "problem" only shows up on machines running 20-year-old
operating systems, how much of a problem is it, really? And how
realistic is that anybody other than Tom will be able to help fix any
issues that we do find, given that probably nobody but Tom has access
to a machine like that? It's sort of sad to think that getting a
modern PostgreSQL to compile on the UNIX machines I used in high
school is probably hopeless, but the flip side is that we can't
realistically maintain ports to systems to which none of us have
access, and we can maintain ports to systems to which only a few of us
have access only if those people are willing to be fairly involved in
fixing any non-trivial issues that pop up.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-12-05 17:18:35 Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.
Previous Message Alvaro Herrera 2016-12-05 16:58:40 Re: pg_dump / copy bugs with "big lines" ?