Обсуждение: Supported platforms list

The supported platforms list in the installation instructions is completely
un-updated for 8.3.  Is this list still useful?  What shall we do with it?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Jan 30, 2008 11:15 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> The supported platforms list in the installation instructions is completely
> un-updated for 8.3.  Is this list still useful?  What shall we do with it?

I think it's important to keep in the docs so people know what we've
tested against. Perhaps refresh it from the green buildfarm members?

/D

On Jan 30, 2008 11:19 AM, Dave Page <dpage@postgresql.org> wrote:
> On Jan 30, 2008 11:15 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > The supported platforms list in the installation instructions is completely
> > un-updated for 8.3.  Is this list still useful?  What shall we do with it?
>
> I think it's important to keep in the docs so people know what we've
> tested against. Perhaps refresh it from the green buildfarm members?

I think it would be an excellent idea for that section to have a URL
pointing to the buildfarm web site, and commenting that platform
combinations that are regularly exercised using the buildfarm are the
ones best-supported by PostgreSQL.
--
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results."  -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling

"Christopher Browne" <cbbrowne@gmail.com> writes:
> On Jan 30, 2008 11:19 AM, Dave Page <dpage@postgresql.org> wrote:
>> On Jan 30, 2008 11:15 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> The supported platforms list in the installation instructions is completely
>>> un-updated for 8.3.  Is this list still useful?  What shall we do with it?
>>
>> I think it's important to keep in the docs so people know what we've
>> tested against. Perhaps refresh it from the green buildfarm members?

> I think it would be an excellent idea for that section to have a URL
> pointing to the buildfarm web site, and commenting that platform
> combinations that are regularly exercised using the buildfarm are the
> ones best-supported by PostgreSQL.

+1 for both of the above suggestions.  I don't think we should remove
the section, since it gives some indication of which other platforms
have been known to work in the past (and likely will still work, despite
the lack of an active buildfarm member).

            regards, tom lane

So someone will need to update that list very soon then.  I don't think we can
release it as is.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Jan 30, 2008 9:59 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> So someone will need to update that list very soon then.  I don't think we can
> release it as is.

Howbeit I'll see about grabbing the existing buildfarm list of HEAD
nodes that are running successfully, and turning that into a CALS
table indicating platforms that seem to be working.  (Actually, a
quick review of the 3 that are presently red suggests that they have
been building well lately, so I expect they only indicate transient
problems.)

I'll see about a patch tomorrow.
--
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results."  -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling

On Jan 30, 2008 11:00 PM, Christopher Browne <cbbrowne@gmail.com> wrote:
> On Jan 30, 2008 9:59 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > So someone will need to update that list very soon then.  I don't think we can
> > release it as is.
>
> Howbeit I'll see about grabbing the existing buildfarm list of HEAD
> nodes that are running successfully, and turning that into a CALS
> table indicating platforms that seem to be working.  (Actually, a
> quick review of the 3 that are presently red suggests that they have
> been building well lately, so I expect they only indicate transient
> problems.)
>
> I'll see about a patch tomorrow.

Attached is a patch.

I have changed the discussion to focus on the buildfarm process, and
it should be recognized that this does change the "shape" of how this
section recognizes platforms as being "supported."

In effect, the new approach is to only recognize platforms for which
there are buildfarm nodes compiling HEAD as being "supported," which
is definitely a change from the past.

This has the conspicuous effect that a number of platforms fall off
the list, notably:
- Red Hat
- Slackware
- HP/UX
- Irix

And there's an interesting paucity of IA-32 platforms.  People are
much more likely to be running x86_64 than IA-32 for buildfarm nodes.

I actually don't have a problem with this.  If anyone is embarrassed
that Red Hat and Slackware have dropped from the "supported" list,
then someone that cares may add a buildfarm node.

But I'm prepared for this to be considered controversial ;-)
--
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results."  -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling

"Christopher Browne" <cbbrowne@gmail.com> writes:
> Attached is a patch.

> I have changed the discussion to focus on the buildfarm process, and
> it should be recognized that this does change the "shape" of how this
> section recognizes platforms as being "supported."

This is exactly *not* what I wanted to do, as it removes all traces
of knowledge about which platforms are likely to work (or not work)
despite not being represented in the current buildfarm.  It also
seems a bit silly to copy-and-paste today's buildfarm roster into
static documentation.

I think citing the buildfarm as the latest authority, and encouraging
people to join it, is a fine thing.  But a mass delete of older info
doesn't seem appropriate IMHO.

> This has the conspicuous effect that a number of platforms fall off
> the list, notably:
> - Red Hat
> - Slackware
> - HP/UX
> - Irix

Can't speak to Slackware or Irix, but IMHO Fedora and HP/UX deserve to
remain listed because I do development/testing work on them every day.
I don't feel a need to run an explicit buildfarm member on my machines
too ;-).  There are probably a few other platforms that are similarly
used by other key developers --- I don't see any indication that Bruce
is running a buildfarm member on whichever-BSD-he-uses, for instance.

            regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 31 Jan 2008 12:29:05 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Can't speak to Slackware or Irix, but IMHO Fedora and HP/UX deserve to

I know of at least one core member who hearts Slackware. :)

Joshua D. Drake


- -- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director |  PostgreSQL political pundit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHogblATb/zqfZUUQRAjpoAKCFsK9ZRGDtiEQjY7/FP43MntHnPACdE1p5
aIVN9uK0N5+fLcOXIiUC1PQ=
=4dxV
-----END PGP SIGNATURE-----

On Jan 31, 2008 5:35 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 31 Jan 2008 12:29:05 -0500
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > Can't speak to Slackware or Irix, but IMHO Fedora and HP/UX deserve to
>
> I know of at least one core member who hearts Slackware. :)

Yeah, but he doesn't have the time to give it the love and attention
it deserves these days and thus spends much more of his time using
Fedora and CentOS :-(

/D

On Jan 31, 2008 5:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Christopher Browne" <cbbrowne@gmail.com> writes:
> > Attached is a patch.
>
> > I have changed the discussion to focus on the buildfarm process, and
> > it should be recognized that this does change the "shape" of how this
> > section recognizes platforms as being "supported."
>
> This is exactly *not* what I wanted to do, as it removes all traces
> of knowledge about which platforms are likely to work (or not work)
> despite not being represented in the current buildfarm.  It also
> seems a bit silly to copy-and-paste today's buildfarm roster into
> static documentation.
>
> I think citing the buildfarm as the latest authority, and encouraging
> people to join it, is a fine thing.  But a mass delete of older info
> doesn't seem appropriate IMHO.

Fair enough.

I took the "most extreme" position, and explained as such, to ensure
that that sort of issue wouldn't be missed :-).

I'll see about adding a secondary table (possibly simply merged with
the "supported in the past" one) which lists those platforms that seem
underrepresented.

I disagree on the matter of it being silly to include a temporal
roster in static documentation.  If we *DO* intend to have some sort
of "list of supported platforms," it is, by necessity, a temporal
list, whatever our data source may be.  I see no problem in "mining"
temporal information from the buildfarm at release time - the list of
active animals generally represents nodes that have been actively
testing PostgreSQL during the release cycle, which is NOT an
irrelevant correlation.  Those nodes have absolutely influenced how
bugs and incompatibilities have been discovered and "stomped"
throughout the cycle.

I have some other writing to do today (some bid/proposal rework that
tends to sap the will to live), so I'll have to pick this back up
tomorrow.  I'll be happy to look at any further suggestions that come
in as input for the next "patch proposal."  (Contrast: I won't be
thinking much about the merits or demerits of Slackware tonight... :-)
)
--
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results."  -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling

I wrote:
> This is exactly *not* what I wanted to do, as it removes all traces
> of knowledge about which platforms are likely to work (or not work)
> despite not being represented in the current buildfarm.  It also
> seems a bit silly to copy-and-paste today's buildfarm roster into
> static documentation.

> I think citing the buildfarm as the latest authority, and encouraging
> people to join it, is a fine thing.  But a mass delete of older info
> doesn't seem appropriate IMHO.

After studying the existing doc in more detail, I've come round to
agreeing with Peter and Chris' position that the existing table no
longer serves any useful purpose.  The interesting part of it is an
indication of which OSes and CPUs we support in general, but that can
be summarized in a few lines, with a pointer to the buildfarm for
concrete details.  Accordingly I've replaced the section with the
attached text.

            regards, tom lane


 <sect1 id="supported-platforms">
  <title>Supported Platforms</title>

  <para>
   A platform (that is, a CPU architecture and operating system combination)
   is considered supported by the <productname>PostgreSQL</> development
   community if the code contains provisions to work on that platform and
   it has recently been verified to build and pass its regression tests
   on that platform.  Currently, most testing of platform compatibility
   is done automatically by test machines in the
   <ulink url="http://buildfarm.postgresql.org/">PostgreSQL Build Farm</ulink>.
   If you are interested in using <productname>PostgreSQL</> on a platform
   that is not represented in the build farm, but on which the code works
   or can be made to work, you are strongly encouraged to set up a build
   farm member machine so that continued compatibility can be assured.
  </para>

  <para>
   In general, <productname>PostgreSQL</> can be expected to work on
   these CPU architectures: x86, x86_64, IA64, PowerPC,
   PowerPC 64, S/390, S/390x, Sparc, Sparc 64, Alpha, ARM, MIPS, MIPSEL, M68K,
   and PA-RISC.  Code support exists for M32R, NS32K, and VAX, but these
   architectures are not known to have been tested recently.  It is often
   possible to build on an unsupported CPU type by configuring with
   <option>--disable-spinlocks</option>, but performance will be poor.
  </para>

  <para>
   <productname>PostgreSQL</> can be expected to work on these operating
   systems: Linux (all recent distributions), Windows (Win2000 SP4 and later),
   FreeBSD, OpenBSD, NetBSD, Mac OS X, AIX, HP/UX, IRIX, Solaris, Tru64 Unix,
   and UnixWare.  Other Unix-like systems may also work but are not currently
   being tested.  In most cases, all CPU architectures supported by
   a given operating system will work.  Look in the <filename>doc/</>
   directory of the source distribution to see if there is a FAQ document
   specific to your operating system, particularly if using an older system.
  </para>

  <para>
   If you have installation problems on a platform that is known
   to be supported according to recent build farm results, please report
   it to <email>pgsql-bugs@postgresql.org</email>.  If you are interested
   in porting <productname>PostgreSQL</> to a new platform,
   <email>pgsql-ports@postgresql.org</email> is the appropriate place
   to discuss that.
  </para>
 </sect1>