On Thu, Sep 13, 2012 at 02:29:08PM +0100, Simon Riggs wrote:
> I think we need an in-between status of
> might-work-will-remove-if-it-doesnt. The key is not whether to remove
> it, the key is whether the lack of support for certain features in an
> old OS is sufficient to prevent forward progress o
On 13 September 2012 14:18, Noah Misch wrote:
> On Thu, Sep 13, 2012 at 10:00:51AM +0100, Simon Riggs wrote:
>> SGI support for IRIX ends in Dec 2013, following on from
>> discontinuation of hardware in 2006/7
>> http://www.sgi.com/services/support/irix_mips_support.html
>>
>> Which means 9.3 will
On Thu, Sep 13, 2012 at 10:00:51AM +0100, Simon Riggs wrote:
> SGI support for IRIX ends in Dec 2013, following on from
> discontinuation of hardware in 2006/7
> http://www.sgi.com/services/support/irix_mips_support.html
>
> Which means 9.3 will not have an IRIX platform to run on for more than
>
On 6 May 2012 15:23, Tom Lane wrote:
> Peter Geoghegan writes:
>> On 6 May 2012 01:06, Robert Haas wrote:
>>> I think we should err on the side of removing less rather than more.
>>> It won't hurt anything much to leave these around for another few
>>> years.
>
>> I think it's better to force us
Peter Geoghegan writes:
> On 6 May 2012 01:06, Robert Haas wrote:
>> I think we should err on the side of removing less rather than more.
>> It won't hurt anything much to leave these around for another few
>> years.
> I think it's better to force users of platforms like IRIX and BSD/OS,
> platf
On 6 May 2012 01:06, Robert Haas wrote:
> On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian wrote:
>> Well, absent user feedback, we could use our own 5-year rule and keep
>> sco and unixware, and remove irix (2006).
>
> I think we should err on the side of removing less rather than more.
> It won't
On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian wrote:
> Well, absent user feedback, we could use our own 5-year rule and keep
> sco and unixware, and remove irix (2006).
I think we should err on the side of removing less rather than more.
It won't hurt anything much to leave these around for anot
On Sat, May 05, 2012 at 12:08:00PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> >> Possibly. What exactly is the difference between the "sco" and
> >> "unixware" ports, anyway? The one buildfarm member we have running
> >> SCO sof
On Sat, May 05, 2012 at 12:08:00PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> >> Possibly. What exactly is the difference between the "sco" and
> >> "unixware" ports, anyway? The one buildfarm member we have running
> >> SCO sof
On 5 May 2012 09:59, Peter Eisentraut wrote:
> Based on these emerging criteria, should we also remove the other
> platforms on my original "marginal" list?
>
> irix
Well, there hasn't been an IRIX release since 2006, and silicon
graphics is defunct. The SGI brand lives on, though I think that th
Bruce Momjian writes:
> On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
>> Possibly. What exactly is the difference between the "sco" and
>> "unixware" ports, anyway? The one buildfarm member we have running
>> SCO software (koi) chooses the unixware template.
> Unixware was based on
On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> >> Furthermore, I would want to insist that a complainer provide a
> >> buildfarm member as the price of us continuing to support an old
> >> uncommon platf
Peter Eisentraut writes:
> On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
>> Furthermore, I would want to insist that a complainer provide a
>> buildfarm member as the price of us continuing to support an old
>> uncommon platform. Otherwise the apparent support is hollow. The BSDI
>> port wa
On Sat, May 05, 2012 at 11:59:54AM +0300, Peter Eisentraut wrote:
> On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> > What's the grounds for asserting they were known not to work? Not
> > actual testing, I assume.
>
> There were either essential pieces missing (e.g., no shared library
> supp
On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> What's the grounds for asserting they were known not to work? Not
> actual testing, I assume.
There were either essential pieces missing (e.g., no shared library
support, or no Makefile.port), or we had received reports in the past
the platform
On fre, 2012-05-04 at 18:16 -0400, Bruce Momjian wrote:
> Not sure where you got 24 hours:
>
> Tues http://archives.postgresql.org/pgsql-hackers/2012-05/msg00061.php
> Wed http://archives.postgresql.org/pgsql-general/2012-05/msg00060.php
> Thur http://archives.postgresql.org/pgsql-commit
On Fri, May 04, 2012 at 06:25:24PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
> >> I'm not so much opposed to removing the port. I am more concerned about
> >> the manner in which it was done. The other ports I removed wer
Bruce Momjian writes:
> On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
>> I'm not so much opposed to removing the port. I am more concerned about
>> the manner in which it was done. The other ports I removed were known
>> to not work anyway, for years, and there were at least
On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
> > On 3 May 2012 17:21, Bruce Momjian wrote:
> > > I think I was the only user left; I have never heard from a BSD/OS user
> > > in the past 5-7 years.
> >
> > I'm incli
On Fri, May 4, 2012 at 8:45 PM, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
>> On 3 May 2012 17:21, Bruce Momjian wrote:
>> > I think I was the only user left; I have never heard from a BSD/OS user
>> > in the past 5-7 years.
>>
>> I'm inclined to agree wi
On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
> On 3 May 2012 17:21, Bruce Momjian wrote:
> > I think I was the only user left; I have never heard from a BSD/OS user
> > in the past 5-7 years.
>
> I'm inclined to agree with Bruce. While it's not reasonable to assume
> that the lack o
On 3 May 2012 17:21, Bruce Momjian wrote:
> I think I was the only user left; I have never heard from a BSD/OS user
> in the past 5-7 years.
I'm inclined to agree with Bruce. While it's not reasonable to assume
that the lack of a BSD/OS user complaining on -general indicates that
there are none,
On Thu, May 03, 2012 at 07:11:47PM +0300, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 10:59 -0400, Bruce Momjian wrote:
> > Having received no replies on "general" from bsdi users considering
> > upgrading to 9.2, I have removed the port.
>
> I think that was quite premature. There is no requ
On tor, 2012-05-03 at 10:59 -0400, Bruce Momjian wrote:
> Having received no replies on "general" from bsdi users considering
> upgrading to 9.2, I have removed the port.
I think that was quite premature. There is no requirement that bsdi
users need to read pgsql-general, especially if you give t
On Tue, May 01, 2012 at 04:39:32PM -0400, Bruce Momjian wrote:
> On Tue, Apr 24, 2012 at 09:29:39PM +0300, Peter Eisentraut wrote:
> > I propose that we remove support for the following OS ports from our
> > source tree. They are totally dead, definitely don't work, and/or
> > probably no one reme
On Tue, Apr 24, 2012 at 09:29:39PM +0300, Peter Eisentraut wrote:
> I propose that we remove support for the following OS ports from our
> source tree. They are totally dead, definitely don't work, and/or
> probably no one remembers what they even were. The code just bit rots
> and is in the way
Robert Haas writes:
> ... I don't feel super-strongly about it, but OTOH I see little
> reason to keep the Univel spinlock implementation if we're removing
> the Univel port.
No, I have no objection to that. I was just questioning the wisdom of
removing CPU-specific s_lock sections on the ground
On Wed, Apr 25, 2012 at 12:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> I have no position on whether those operating systems are dead enough
>> to warrant removing support, but on a related point, I would like it
>> if we could get rid of as many spinlock implementations as are
>> applicable
Robert Haas writes:
> I have no position on whether those operating systems are dead enough
> to warrant removing support, but on a related point, I would like it
> if we could get rid of as many spinlock implementations as are
> applicable only to platforms that are effectively defunct. I'm
> su
On Tue, Apr 24, 2012 at 9:49 PM, Robert Haas wrote:
> I'm
> suspicious of s_lock.h's support for National Semiconductor 32K,
> Renesas' M32R, Renesas' SuperH, UNIVEL, SINIX / Reliant UNIX,
> Nextstep, and Sun3
Were there ever multiprocessor Nextstep or Sun3 machines anyways?
Wouldn't someone on
On Tue, Apr 24, 2012 at 2:29 PM, Peter Eisentraut wrote:
> I propose that we remove support for the following OS ports from our
> source tree. They are totally dead, definitely don't work, and/or
> probably no one remembers what they even were. The code just bit rots
> and is in the way of futur
On 04/24/2012 08:29 PM, Peter Eisentraut wrote:
> I propose that we remove support for the following OS ports from our
> source tree. They are totally dead, definitely don't work, and/or
> probably no one remembers what they even were. The code just bit rots
> and is in the way of future improvem
I propose that we remove support for the following OS ports from our
source tree. They are totally dead, definitely don't work, and/or
probably no one remembers what they even were. The code just bit rots
and is in the way of future improvements.
* Dead/remove:
dgux
nextstep
sunos4
svr4
ultrix4
33 matches
Mail list logo
