Обсуждение: Add AIX on the PostgreSQL Download page

On 9/7/21 4:06 AM, REIX, Tony wrote:
> Hi,
>
> I am interested in knowing if AIX could be added to the PostgreSQL page
> https://www.postgresql.org/download/ , either as a link to a PostgreSQL
> web-site page where instructions can be given and updated about where to
> get RPMs for AIX and how to install them, plus news about new versions
> and releases, or a link to a page out of PostgreSQL web-site.
>
> We (Bull/ATOS BullFreeware: http://www.bullfreeware.com,  and IBM AIX
> ToolBox:
> https://www.ibm.com/support/pages/aix-toolbox-linux-applications-overview)
> are providing OpenSource packages (inc. PostgreSQL) for AIX under RPM
> format since ages and we'd like to enable PostgreSQL for AIX to be more
> visible by PostgreSQL users.

Looking at the available packages[1], it does not appear that all of the
community supported versions are updated (e.g. the last 9.6 updates were
in 2018). It also seems that package updates are random -- e.g. there
was a 13.1 release, and a 13.4 release, which misses several bug fix +
security releases, and they come out several weeks after the release.

I'd be more open to this if the packages themselves were hosted on
community infrastructure and were consistent with the rest of the
packaging projects. Right now I'm -1 on this; additionally, I'm
generally -1 to adding more additional offsite links to downloads.

Thanks,

Jonathan

[1]
http://www.bullfreeware.com/?searching=true&package=postgresql&from=&to=&libraries=false&exact=false&version=5

> On 7 Sep 2021, at 16:10, Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> On 9/7/21 4:06 AM, REIX, Tony wrote:
>> Hi,
>>
>> I am interested in knowing if AIX could be added to the PostgreSQL page
>> https://www.postgresql.org/download/ , either as a link to a PostgreSQL
>> web-site page where instructions can be given and updated about where to
>> get RPMs for AIX and how to install them, plus news about new versions
>> and releases, or a link to a page out of PostgreSQL web-site.
>>
>> We (Bull/ATOS BullFreeware: http://www.bullfreeware.com,  and IBM AIX
>> ToolBox:
>> https://www.ibm.com/support/pages/aix-toolbox-linux-applications-overview)
>> are providing OpenSource packages (inc. PostgreSQL) for AIX under RPM
>> format since ages and we'd like to enable PostgreSQL for AIX to be more
>> visible by PostgreSQL users.
>
> Looking at the available packages[1], it does not appear that all of the
> community supported versions are updated (e.g. the last 9.6 updates were
> in 2018). It also seems that package updates are random -- e.g. there
> was a 13.1 release, and a 13.4 release, which misses several bug fix +
> security releases, and they come out several weeks after the release.

Do we have a strict policy around this?  Some package managers are still at
13.3 ~ a month out and the Fink macOS package manager doesn’t have v13 at all
AFAICT?

> I'd be more open to this if the packages themselves were hosted on
> community infrastructure and were consistent with the rest of the
> packaging projects.

That seems a high bar to cross given that we don’t host macOS, Windows and the
BSD’s today but link to those.

> Right now I'm -1 on this; additionally, I'm
> generally -1 to adding more additional offsite links to downloads.

Unrelated but semi-related, if we don’t want new links we should probably
remove the Solaris download link which doesn’t even link to downloadable
packages.

--
Daniel Gustafsson        https://vmware.com/

On 9/7/21 10:57 AM, Dave Page wrote:
>
>
> On Tue, Sep 7, 2021 at 3:26 PM Daniel Gustafsson <daniel@yesql.se
> <mailto:daniel@yesql.se>> wrote:
>
>     > On 7 Sep 2021, at 16:10, Jonathan S. Katz <jkatz@postgresql.org
>     <mailto:jkatz@postgresql.org>> wrote:

>     > I'd be more open to this if the packages themselves were hosted on
>     > community infrastructure and were consistent with the rest of the
>     > packaging projects.
>
>     That seems a high bar to cross given that we don’t host macOS,
>     Windows and the
>     BSD’s today but link to those.
>
>
> I agree.

It doesn't mean we need to continue to exacerbate the situation by
linking to downloads that we have little control over.

For example, what happens when the external downloads are unavailable?
We had a recent incident where this exact scenario happened. There are
now some reporting mechanisms in place to handle that scenario, but
ultimately it comes back to "PostgreSQL is unavailable for download."

>     > Right now I'm -1 on this; additionally, I'm
>     > generally -1 to adding more additional offsite links to downloads.
>
>     Unrelated but semi-related, if we don’t want new links we should
>     probably
>     remove the Solaris download link which doesn’t even link to downloadable
>     packages.
>
>
> +1

IIRC we had left that up so we could sunset it and provide "forwarding
information." Given it's been ~1 year, we could likely remove it.

Jonathan

On Tue, Sep 7, 2021 at 5:07 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> >     > Right now I'm -1 on this; additionally, I'm
> >     > generally -1 to adding more additional offsite links to downloads.
> >
> >     Unrelated but semi-related, if we don’t want new links we should
> >     probably
> >     remove the Solaris download link which doesn’t even link to downloadable
> >     packages.
> >
> >
> > +1
>
> IIRC we had left that up so we could sunset it and provide "forwarding
> information." Given it's been ~1 year, we could likely remove it.

That sunsetting happened on May 17, 2021. That's definitely not a
year...  I think we should keep it for a while -- but we could remove
it from the index page.

--
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

> On 7 Sep 2021, at 17:07, Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> On 9/7/21 10:57 AM, Dave Page wrote:
>>
>>
>> On Tue, Sep 7, 2021 at 3:26 PM Daniel Gustafsson <daniel@yesql.se
>> <mailto:daniel@yesql.se>> wrote:
>>
>>> On 7 Sep 2021, at 16:10, Jonathan S. Katz <jkatz@postgresql.org
>>    <mailto:jkatz@postgresql.org>> wrote:
>
>>> I'd be more open to this if the packages themselves were hosted on
>>> community infrastructure and were consistent with the rest of the
>>> packaging projects.
>>
>>    That seems a high bar to cross given that we don’t host macOS,
>>    Windows and the
>>    BSD’s today but link to those.
>>
>> I agree.
>
> It doesn't mean we need to continue to exacerbate the situation by
> linking to downloads that we have little control over.
>
> For example, what happens when the external downloads are unavailable?
> We had a recent incident where this exact scenario happened. There are
> now some reporting mechanisms in place to handle that scenario, but
> ultimately it comes back to "PostgreSQL is unavailable for download."

That is an argument against any outbound links though.  Not having the
information in the first place doesn’t seem to make PostgreSQL more available
than the risk of an intermittent 404.

I don’t have strong feelings wrt AIX, nor insights into the current proposal,
but limiting the offering based on what has been effectively grandfathered in
based on fears about future shortcomings in network availability doesn’t seem
to improve user friendliness.  Having the packages on offer in the first place,
as discussed downthread, is another matter though and a very real one.

--
Daniel Gustafsson        https://vmware.com/

On 9/7/21 12:21 PM, Daniel Gustafsson wrote:
>> On 7 Sep 2021, at 17:07, Jonathan S. Katz <jkatz@postgresql.org> wrote:
>>
>> On 9/7/21 10:57 AM, Dave Page wrote:
>>>
>>>
>>> On Tue, Sep 7, 2021 at 3:26 PM Daniel Gustafsson <daniel@yesql.se
>>> <mailto:daniel@yesql.se>> wrote:
>>>
>>>> On 7 Sep 2021, at 16:10, Jonathan S. Katz <jkatz@postgresql.org
>>>    <mailto:jkatz@postgresql.org>> wrote:
>>
>>>> I'd be more open to this if the packages themselves were hosted on
>>>> community infrastructure and were consistent with the rest of the
>>>> packaging projects.
>>>
>>>    That seems a high bar to cross given that we don’t host macOS,
>>>    Windows and the
>>>    BSD’s today but link to those.
>>>
>>> I agree.
>>
>> It doesn't mean we need to continue to exacerbate the situation by
>> linking to downloads that we have little control over.
>>
>> For example, what happens when the external downloads are unavailable?
>> We had a recent incident where this exact scenario happened. There are
>> now some reporting mechanisms in place to handle that scenario, but
>> ultimately it comes back to "PostgreSQL is unavailable for download."
>
> That is an argument against any outbound links though.  Not having the
> information in the first place doesn’t seem to make PostgreSQL more available
> than the risk of an intermittent 404.

I'm not against having outbound links -- in fact I help moderate quite a
few of those that we host on .org, and I'm glad we do so.

Downloads are different -- they are often one's first impression of
PostgreSQL, and they are a critical piece of the user experience, i.e.
how one actually accesses PostgreSQL.

This is why I continuously recommend that we try to host them on our own
infrastructure, so that way we have maximum control over this experience.

> I don’t have strong feelings wrt AIX, nor insights into the current proposal,
> but limiting the offering based on what has been effectively grandfathered in
> based on fears about future shortcomings in network availability doesn’t seem
> to improve user friendliness.

Network availability is only one aspect of this. There's the actual
package availability (as you pointed out with Fink -- and I'm pretty
sure Dave & I had extensively discussed this in the past).

>  Having the packages on offer in the first place,
> as discussed downthread, is another matter though and a very real one.

Don't get me wrong, I'm glad that Tony + ATOS/Bull are offering to
support the AIX packages for PostgreSQL. I think it's very generous. I
know secondhand the pain it takes to maintain and build packages, and
I'm appreciative of anyone who wants to do so for PostgreSQL.

However, my point is that the packages should ultimately be hosted on
community infrastructure.

Thanks,

Jonathan

> On Sep 7, 2021, at 10:52, Jonathan S. Katz <jkatz@postgresql.org> wrote:
> However, my point is that the packages should ultimately be hosted on
> community infrastructure.

I don't think it's viable to insist that all packages be downloaded from the pg.org infrastructure.  It's reasonable to
saythat we won't link directly to a download, but will link to a third-party website where the packages are made
available.

On 2021-09-08 03:52, Jonathan S. Katz wrote:
<snip>
> Don't get me wrong, I'm glad that Tony + ATOS/Bull are offering to
> support the AIX packages for PostgreSQL.

+1


> I think it's very generous. I
> know secondhand the pain it takes to maintain and build packages, and
> I'm appreciative of anyone who wants to do so for PostgreSQL.
> 
> However, my point is that the packages should ultimately be hosted on
> community infrastructure.

Are we willing to give Tony/ATOS/Bull write access to a Community infra
location to enable that?

* If so, then potential ideas for how can probably be discussed and
   maybe worked out.
* If not, seems like we'll be pointing to their servers. ;)

+ Justin

On Tue, Sep 7, 2021 at 7:56 PM Christophe Pettus <xof@thebuild.com> wrote:
>
>
>
> > On Sep 7, 2021, at 10:52, Jonathan S. Katz <jkatz@postgresql.org> wrote:
> > However, my point is that the packages should ultimately be hosted on
> > community infrastructure.
>
> I don't think it's viable to insist that all packages be downloaded from the pg.org infrastructure.  It's reasonable
tosay that we won't link directly to a download, but will link to a third-party website where the packages are made
available.
>

I agree that it's not viable to insist they're all downloaded from
"us", and there are sometimes good reasons for it. For example, the
*BSD ports system kind of relies on it being off their systems and not
off ours, but we still want to point to that.

I think it would make sense to more clearly indicate *when* the
download is off a third party site vs when it's from something the
community runs, as a general rule. That would also clear up some of
the confusion when people have issues. And that should be applied
across the board.

It would probably also make sense to have some leve of at leas ta
"soft SLA" defined as a requirement to get listed. Like putting out
patches within <x> time of a release for example -- I think that would
be a perfectly reasonable requirement to put out there. And no, we
can't follow up on every single one of them, but if we get repeated
reports of something not being properly maintained we can remove it
from our list.

But we also need to make sure we don't end up being a link factory for
companies or organisations who just want to get clicks, and do so by
hosting an installer. In fact, from that perspective it might b better
to actually  link to a direct binary if possible rather than a
website. But that's also going to be expensive on maintenance. But we
probably *should* put a hard rule in place wrt the amount of tracking
etc that can be done on the resulting page(s) being linked to.


-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

> On Sep 7, 2021, at 12:35, Magnus Hagander <magnus@hagander.net> wrote:
>
> But we also need to make sure we don't end up being a link factory for
> companies or organisations who just want to get clicks, and do so by
> hosting an installer.

It's a bit of a balancing act, because one of the ways a commercial organization can justify the (non-trivial) cost of
preparingpackages or an installer is that it is a good marketing tool.  At the minimum, we should require that the
installerbe downlaodable without any registration or information collection. 

On Tue, Sep 7, 2021 at 10:07 PM Christophe Pettus <xof@thebuild.com> wrote:
>
>
>
> > On Sep 7, 2021, at 12:35, Magnus Hagander <magnus@hagander.net> wrote:
> >
> > But we also need to make sure we don't end up being a link factory for
> > companies or organisations who just want to get clicks, and do so by
> > hosting an installer.
>
> It's a bit of a balancing act, because one of the ways a commercial organization can justify the (non-trivial) cost
ofpreparing packages or an installer is that it is a good marketing tool.  At the minimum, we should require that the
installerbe downlaodable without any registration or information collection. 

Certainly, and I'm fine with that. I mean what we want to avoid is
having 5 different links for each platform going to differen companies
who're doing that as a way to drive traffic only. But yes as you say,
it's a balance.

--
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

> On 7 Sep 2021, at 22:08, Magnus Hagander <magnus@hagander.net> wrote:
> On Tue, Sep 7, 2021 at 10:07 PM Christophe Pettus <xof@thebuild.com> wrote:
>>> On Sep 7, 2021, at 12:35, Magnus Hagander <magnus@hagander.net> wrote:

>>> But we also need to make sure we don't end up being a link factory for
>>> companies or organisations who just want to get clicks, and do so by
>>> hosting an installer.
>>
>> It's a bit of a balancing act, because one of the ways a commercial organization can justify the (non-trivial) cost
ofpreparing packages or an installer is that it is a good marketing tool.  At the minimum, we should require that the
installerbe downlaodable without any registration or information collection. 
>
> Certainly, and I'm fine with that. I mean what we want to avoid is
> having 5 different links for each platform going to differen companies
> who're doing that as a way to drive traffic only.

I don’t think there is a huge risk in any company making the investment into
packaging and/or writing and maintaining an up-to-date installer purely for
traffic, that would be very expensive traffic.  If they do make a high-quality
installer that people like and anyone can use for free without registration (I
would expect us to have such reqs in place for linking) only to get the
traffic, then that’s not necessarily bad for the community is it?

--
Daniel Gustafsson        https://vmware.com/

Hi Tony,

On 9/21/21 4:04 AM, REIX, Tony wrote:
> Hello,
>
> Any news about this subject?

Let's revisit after the PostgreSQL 14 release next week, as this is
unlikely to advance before then.

Thanks,

Jonathan

On Tue, Sep 21, 2021 at 10:49:15AM -0400, Jonathan Katz wrote:
> Hi Tony,
> 
> On 9/21/21 4:04 AM, REIX, Tony wrote:
> > Hello,
> > 
> > Any news about this subject?
> 
> Let's revisit after the PostgreSQL 14 release next week, as this is
> unlikely to advance before then.

Can we talk about this now that PG 14 has been released?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.

On 10/7/21 2:24 PM, Bruce Momjian wrote:
> On Tue, Sep 21, 2021 at 10:49:15AM -0400, Jonathan Katz wrote:
>> Hi Tony,
>>
>> On 9/21/21 4:04 AM, REIX, Tony wrote:
>>> Hello,
>>>
>>> Any news about this subject?
>>
>> Let's revisit after the PostgreSQL 14 release next week, as this is
>> unlikely to advance before then.
>
> Can we talk about this now that PG 14 has been released?

Sure.

I went to check the website[1] and see that since we last spoke, there
are now updated packages for PG 11, 12, and 13. I don't see new ones for
10 or 14, though understandably 14 is new. In this case I'll discount
9.6 given it has one more release.

My opinion is pretty much unchanged in terms of linking offsite; I'd
prefer that we host packages on community infrastructure.

However, I'll accommodate whatever the general consensus is, and if
that's linking offsite I'll gladly work on a patch for that when the
time is right.

Thanks,

Jonathan


[1]
http://www.bullfreeware.com/?searching=true&package=postgresql&from=&to=&libraries=false&exact=false&version=5

> On 7 Oct 2021, at 20:31, Jonathan S. Katz <jkatz@postgresql.org> wrote:

> My opinion is pretty much unchanged in terms of linking offsite; I'd
> prefer that we host packages on community infrastructure.

I still think it's a too large ask to enforce hosting by pginfra, considering
how many exceptions we'd have to punch in such a policy to accomodate for
various package managers.

--
Daniel Gustafsson        https://vmware.com/