Re: Adding PGInstaller to the Downloads section

Hi,

Please find attached a patch to add PGInstaller to the Downloads section of
postgresql.org.

PGInstaller offers an easy way to install PostgreSQL. We have found this to
be crucial to our customers who are used to GUI-based, click-n-point
installers on Windows and at times on macOS. PGInstaller has evolved from
2UDA, a package that 2ndQuadrant has been working on for more than 3 years.

2ndQuadrant is committed to developing and actively maintaining PGInstaller
for PostgreSQL versions 9.5 and above. We have been releasing, and will
continue to release, updates in sync with the PostgreSQL community, most
recently announcing the minor release on 9-Aug. PGInstaller has also kept
up with the Beta releases for PostgreSQL 11.

Thanks!

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

*bump*

On Tue, Aug 21, 2018 at 9:57 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
wrote:

> Hi,
>
> Please find attached a patch to add PGInstaller to the Downloads section
> of postgresql.org.
>
> PGInstaller offers an easy way to install PostgreSQL. We have found this
> to be crucial to our customers who are used to GUI-based, click-n-point
> installers on Windows and at times on macOS. PGInstaller has evolved from
> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>
> 2ndQuadrant is committed to developing and actively maintaining
> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
> and will continue to release, updates in sync with the PostgreSQL
> community, most recently announcing the minor release on 9-Aug. PGInstaller
> has also kept up with the Beta releases for PostgreSQL 11.
>
> Thanks!
>
> --
> Umair Shahid
> Head of Marketing & Products
> 2ndQuadrant - The team of diligent PostgreSQL experts
> https://www.2ndQuadrant.com/
>

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

Hi

On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
wrote:

> Hi,
>
> Please find attached a patch to add PGInstaller to the Downloads section
> of postgresql.org.
>
> PGInstaller offers an easy way to install PostgreSQL. We have found this
> to be crucial to our customers who are used to GUI-based, click-n-point
> installers on Windows and at times on macOS. PGInstaller has evolved from
> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>
> 2ndQuadrant is committed to developing and actively maintaining
> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
> and will continue to release, updates in sync with the PostgreSQL
> community, most recently announcing the minor release on 9-Aug. PGInstaller
> has also kept up with the Beta releases for PostgreSQL 11.
>

The first issue that I can see (or more correctly, not see), is the source
code. All packages on these pages need to be 100% Open Source, including
the code required to build the packages themselves (but not necessarily the
tools/compilers of course). Where can the code be found?

Secondly, it looks like your ordering is not quite as it should be on some
pages. We list native packages first, followed by non-native, then third
party packaging systems, with new additions at the end of the appropriate
section to limit confusion for users (particularly those who pick the first
item then later try to upgrade it).

E.g. on the Ubuntu page, it should be:

PG APT Repo
BigSQL DEB Packages
EDB Installers
2ndQ Installers

On the Mac page:

EDB Installers
BigSQL Installers
Postgres.app
2ndQ Installers

Similarly for other pages.

Finally; "PGInstaller" is the name used by the original Windows packaging
that Magnus and I used to maintain (
http://pgfoundry.org/projects/pginstaller/) I for one would appreciate it
if you didn't use that name, but came up with something original.

Thanks.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Aug 28, 2018 at 1:01 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>

Thanks, Dave, for picking that one up. I had it on my list to deal with but
it somehow slipped out of my inbox.

On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
> wrote:
>
>> Hi,
>>
>> Please find attached a patch to add PGInstaller to the Downloads section
>> of postgresql.org.
>>
>> PGInstaller offers an easy way to install PostgreSQL. We have found this
>> to be crucial to our customers who are used to GUI-based, click-n-point
>> installers on Windows and at times on macOS. PGInstaller has evolved from
>> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>>
>> 2ndQuadrant is committed to developing and actively maintaining
>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>> and will continue to release, updates in sync with the PostgreSQL
>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>> has also kept up with the Beta releases for PostgreSQL 11.
>>
>
> The first issue that I can see (or more correctly, not see), is the source
> code. All packages on these pages need to be 100% Open Source, including
> the code required to build the packages themselves (but not necessarily the
> tools/compilers of course). Where can the code be found?
>

In fact, I'd like to take this opportunity to suggest another restructure.
(which I've been thinking about for a while, but this makes it more current)

I think for the distribution specific ones, we should really only keep the
community provided or recommended ones. That means on debian/ubuntu pages
we keep only apt.pg.org and "included in distro". For redhat/ubuntu we keep
only yum.pg.org and "included in distro". That goes for all the platforms
that we have clear recommendations on.

The other installers, including this new one from 2ndquadrant, gets moved
to "3rd party distributions" on /download/, which
may now possibly need a sub-page with all of them on. (Incidentally, this
is where 2UDA already is).

The remaining question then becomes Windows and Mac. My personal view is
keep the EDB installer on the Windows one, but consider keeping
postgres.app instead on Mac (along with references to things like homebrew)
as that seems to resonate with what people actually want on that platform.
But I'm not a Mac user myself, so somebody who is might have an argument
for keeping others there instead.

The idea ehind ghit is, of course, to simplify things for our users. Right
now we quite honestly provide more options than they need. It's good to
have those, but it's also good to have a very straight forward path for
those who don't have any non-standard needs. Each page can be given a
"there are also a number of third party options available, <click here> to
see them".

Finally; "PGInstaller" is the name used by the original Windows packaging
> that Magnus and I used to maintain (http://pgfoundry.org/projects
> /pginstaller/). I for one would appreciate it if you didn't use that
> name, but came up with something original.
>
>
+1. (And for the record, I still get mailman spam for pginstaller now and
then :P So while we may think it's dead, it's definitely playing zombie now
and then)

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

On Tue, Aug 28, 2018 at 12:11 PM, Magnus Hagander <magnus(at)hagander(dot)net>
wrote:

> On Tue, Aug 28, 2018 at 1:01 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> Hi
>>
>
> Thanks, Dave, for picking that one up. I had it on my list to deal with
> but it somehow slipped out of my inbox.
>
>
> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <
>> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>
>>> Hi,
>>>
>>> Please find attached a patch to add PGInstaller to the Downloads section
>>> of postgresql.org.
>>>
>>> PGInstaller offers an easy way to install PostgreSQL. We have found this
>>> to be crucial to our customers who are used to GUI-based, click-n-point
>>> installers on Windows and at times on macOS. PGInstaller has evolved from
>>> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>>>
>>> 2ndQuadrant is committed to developing and actively maintaining
>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>> and will continue to release, updates in sync with the PostgreSQL
>>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>>> has also kept up with the Beta releases for PostgreSQL 11.
>>>
>>
>> The first issue that I can see (or more correctly, not see), is the
>> source code. All packages on these pages need to be 100% Open Source,
>> including the code required to build the packages themselves (but not
>> necessarily the tools/compilers of course). Where can the code be found?
>>
>
> In fact, I'd like to take this opportunity to suggest another restructure.
> (which I've been thinking about for a while, but this makes it more current)
>
> I think for the distribution specific ones, we should really only keep the
> community provided or recommended ones. That means on debian/ubuntu pages
> we keep only apt.pg.org and "included in distro". For redhat/ubuntu we
> keep only yum.pg.org and "included in distro". That goes for all the
> platforms that we have clear recommendations on.
>
> The other installers, including this new one from 2ndquadrant, gets moved
> to "3rd party distributions" on /download/,
> which may now possibly need a sub-page with all of them on. (Incidentally,
> this is where 2UDA already is).
>

I could go with that.

>
> The remaining question then becomes Windows and Mac. My personal view is
> keep the EDB installer on the Windows one, but consider keeping
> postgres.app instead on Mac (along with references to things like homebrew)
> as that seems to resonate with what people actually want on that platform.
> But I'm not a Mac user myself, so somebody who is might have an argument
> for keeping others there instead.
>

Postgres.app has a very different design goal than the other Mac packages;
I think we need both options there. I'd also note that some of the
back-branch versions of Postgres.app are quite out of date which is a
problem in of itself.

(and FWIW, I still think that Homebrew should be removed and cast into a
pit of fire for the futzing it does with permissions/ownership of
/usr/local/)

>
> The idea ehind ghit is, of course, to simplify things for our users. Right
> now we quite honestly provide more options than they need. It's good to
> have those, but it's also good to have a very straight forward path for
> those who don't have any non-standard needs. Each page can be given a
> "there are also a number of third party options available, <click here> to
> see them".
>
>
> Finally; "PGInstaller" is the name used by the original Windows packaging
>> that Magnus and I used to maintain (http://pgfoundry.org/projects
>> /pginstaller/). I for one would appreciate it if you didn't use that
>> name, but came up with something original.
>>
>>
> +1. (And for the record, I still get mailman spam for pginstaller now and
> then :P So while we may think it's dead, it's definitely playing zombie now
> and then)
>
> --
> Magnus Hagander
> Me: https://www.hagander.net/ <http://www.hagander.net/>
> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi Dave
On Tue, Aug 28, 2018 at 4:01 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <
> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>
>> Hi,
>>
>> Please find attached a patch to add PGInstaller to the Downloads section
>> of postgresql.org.
>>
>> PGInstaller offers an easy way to install PostgreSQL. We have found this
>> to be crucial to our customers who are used to GUI-based, click-n-point
>> installers on Windows and at times on macOS. PGInstaller has evolved from
>> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>>
>> 2ndQuadrant is committed to developing and actively maintaining
>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>> and will continue to release, updates in sync with the PostgreSQL
>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>> has also kept up with the Beta releases for PostgreSQL 11.
>>
>
> The first issue that I can see (or more correctly, not see), is the source
> code. All packages on these pages need to be 100% Open Source, including
> the code required to build the packages themselves (but not necessarily the
> tools/compilers of course). Where can the code be found?
>

I didn't realize that was a requirement. Let me work with the team
internally to open the source code.

>
> Secondly, it looks like your ordering is not quite as it should be on some
> pages. We list native packages first, followed by non-native, then third
> party packaging systems, with new additions at the end of the appropriate
> section to limit confusion for users (particularly those who pick the first
> item then later try to upgrade it).
>
> E.g. on the Ubuntu page, it should be:
>
> PG APT Repo
> BigSQL DEB Packages
> EDB Installers
> 2ndQ Installers
>
> On the Mac page:
>
> EDB Installers
> BigSQL Installers
> Postgres.app
> 2ndQ Installers
>
> Similarly for other pages.
>

We can work on that.

>
> Finally; "PGInstaller" is the name used by the original Windows packaging
> that Magnus and I used to maintain (
> http://pgfoundry.org/projects/pginstaller/) I for one would appreciate
> it if you didn't use that name, but came up with something original.
>

Given Magnus' email that this is not a completely dead project, I think
that's reasonable. I'll get back on this thread with the requested changes.

>
> Thanks.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

On Tue, Aug 28, 2018 at 4:11 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:

> On Tue, Aug 28, 2018 at 1:01 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> Hi
>>
>
> Thanks, Dave, for picking that one up. I had it on my list to deal with
> but it somehow slipped out of my inbox.
>
>
> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <
>> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>
>>> Hi,
>>>
>>> Please find attached a patch to add PGInstaller to the Downloads section
>>> of postgresql.org.
>>>
>>> PGInstaller offers an easy way to install PostgreSQL. We have found this
>>> to be crucial to our customers who are used to GUI-based, click-n-point
>>> installers on Windows and at times on macOS. PGInstaller has evolved from
>>> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>>>
>>> 2ndQuadrant is committed to developing and actively maintaining
>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>> and will continue to release, updates in sync with the PostgreSQL
>>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>>> has also kept up with the Beta releases for PostgreSQL 11.
>>>
>>
>> The first issue that I can see (or more correctly, not see), is the
>> source code. All packages on these pages need to be 100% Open Source,
>> including the code required to build the packages themselves (but not
>> necessarily the tools/compilers of course). Where can the code be found?
>>
>
> In fact, I'd like to take this opportunity to suggest another restructure.
> (which I've been thinking about for a while, but this makes it more current)
>
> I think for the distribution specific ones, we should really only keep the
> community provided or recommended ones. That means on debian/ubuntu pages
> we keep only apt.pg.org and "included in distro". For redhat/ubuntu we
> keep only yum.pg.org and "included in distro". That goes for all the
> platforms that we have clear recommendations on.
>
> The other installers, including this new one from 2ndquadrant, gets moved
> to "3rd party distributions" on /download/,
> which may now possibly need a sub-page with all of them on. (Incidentally,
> this is where 2UDA already is).
>
> The remaining question then becomes Windows and Mac. My personal view is
> keep the EDB installer on the Windows one, but consider keeping
> postgres.app instead on Mac (along with references to things like homebrew)
> as that seems to resonate with what people actually want on that platform.
> But I'm not a Mac user myself, so somebody who is might have an argument
> for keeping others there instead.
>

I can understand keeping PGDG's apt and yum repositories as the community
provided/recommended sources for distribution specific ones. I am not sure
I understand the reasoning behind the Windows suggestion though. Are you
proposing that the community starts recommending the use of EDB installers
for Windows?

>
> The idea ehind ghit is, of course, to simplify things for our users. Right
> now we quite honestly provide more options than they need. It's good to
> have those, but it's also good to have a very straight forward path for
> those who don't have any non-standard needs. Each page can be given a
> "there are also a number of third party options available, <click here> to
> see them".
>

+1 for simplicity

>
>
> Finally; "PGInstaller" is the name used by the original Windows packaging
>> that Magnus and I used to maintain (
>> http://pgfoundry.org/projects/pginstaller/) I for one would appreciate
>> it if you didn't use that name, but came up with something original.
>>
>>
> +1. (And for the record, I still get mailman spam for pginstaller now and
> then :P So while we may think it's dead, it's definitely playing zombie now
> and then)
>

:-)

I'll get back with a revised patch

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

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

> On Aug 28, 2018, at 7:34 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>
>
> On Tue, Aug 28, 2018 at 12:11 PM, Magnus Hagander <magnus(at)hagander(dot)net <mailto:magnus(at)hagander(dot)net>> wrote:
> On Tue, Aug 28, 2018 at 1:01 PM, Dave Page <dpage(at)pgadmin(dot)org <mailto:dpage(at)pgadmin(dot)org>> wrote:
> Hi
>
> Thanks, Dave, for picking that one up. I had it on my list to deal with but it somehow slipped out of my inbox.
>
>
> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com <mailto:umair(dot)shahid(at)2ndquadrant(dot)com>>wrote:
> Hi,
>
> Please find attached a patch to add PGInstaller to the Downloads section of postgresql.org <http://postgresql.org/>.
>
> PGInstaller offers an easy way to install PostgreSQL. We have found this to be crucial to our customers who are used to GUI-based, click-n-point installers on Windows and at times on macOS. PGInstaller has evolved from 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>
> 2ndQuadrant is committed to developing and actively maintaining PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing, and will continue to release, updates in sync with the PostgreSQL community, most recently announcing the minor release on 9-Aug. PGInstaller has also kept up with the Beta releases for PostgreSQL 11.
>
> The first issue that I can see (or more correctly, not see), is the source code. All packages on these pages need to be 100% Open Source, including the code required to build the packages themselves (but not necessarily the tools/compilers of course). Where can the code be found?
>
> In fact, I'd like to take this opportunity to suggest another restructure. (which I've been thinking about for a while, but this makes it more current)
>
> I think for the distribution specific ones, we should really only keep the community provided or recommended ones. That means on debian/ubuntu pages we keep only apt.pg.org <http://apt.pg.org/> and "included in distro". For redhat/ubuntu we keep only yum.pg.org <http://yum.pg.org/> and "included in distro". That goes for all the platforms that we have clear recommendations on.
>
> The other installers, including this new one from 2ndquadrant, gets moved to "3rd party distributions" on /download/ </download/>, which may now possibly need a sub-page with all of them on. (Incidentally, this is where 2UDA already is).
>
> I could go with that.

+1. Happy to draft up a patch with some screenshots to demonstrate
what this would look like.

>
>
> The remaining question then becomes Windows and Mac. My personal view is keep the EDB installer on the Windows one, but consider keeping postgres.app instead on Mac (along with references to things like homebrew) as that seems to resonate with what people actually want on that platform. But I'm not a Mac user myself, so somebody who is might have an argument for keeping others there instead.
>
> Postgres.app has a very different design goal than the other Mac packages; I think we need both options there. I'd also note that some of the back-branch versions of Postgres.app are quite out of date which is a problem in of itself.
>
> (and FWIW, I still think that Homebrew should be removed and cast into a pit of fire for the futzing it does with permissions/ownership of /usr/local/)

If you could reword this with “Homebrew has demonstrative issues that could
affect the security of running PostgreSQL on OSX/MacOS” perhaps we could
drop it in this release, or add language “We don’t recommend installing PostgreSQL
with Homebrew because of blah blah blah.”

That said, I’d like to confirm that is still true prior to making that decision.

> The idea ehind ghit is, of course, to simplify things for our users. Right now we quite honestly provide more options than they need. It's good to have those, but it's also good to have a very straight forward path for those who don't have any non-standard needs. Each page can be given a "there are also a number of third party options available, <click here> to see them".
>
>
> Finally; "PGInstaller" is the name used by the original Windows packaging that Magnus and I used to maintain (http://pgfoundry.org/projects/pginstaller/ <http://pgfoundry.org/projects/pginstaller/>). I for one would appreciate it if you didn't use that name, but came up with something original.
>
>
> +1. (And for the record, I still get mailman spam for pginstaller now and then :P So while we may think it's dead, it's definitely playing zombie now and then)

…I feel like that should go in a “fun fact” section somewhere on the site. Wiki? :-)

Jonathan

On Tue, Aug 28, 2018 at 1:31 PM, Jonathan S. Katz <jkatz(at)postgresql(dot)org>
wrote:

>
> On Aug 28, 2018, at 7:34 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>
>
> On Tue, Aug 28, 2018 at 12:11 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
>
>> On Tue, Aug 28, 2018 at 1:01 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>
>> Thanks, Dave, for picking that one up. I had it on my list to deal with
>> but it somehow slipped out of my inbox.
>>
>>
>> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <umair.shahid@
>>> 2ndquadrant.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find attached a patch to add PGInstaller to the Downloads
>>>> section of postgresql.org.
>>>>
>>>> PGInstaller offers an easy way to install PostgreSQL. We have found
>>>> this to be crucial to our customers who are used to GUI-based,
>>>> click-n-point installers on Windows and at times on macOS. PGInstaller has
>>>> evolved from 2UDA, a package that 2ndQuadrant has been working on for more
>>>> than 3 years.
>>>>
>>>> 2ndQuadrant is committed to developing and actively maintaining
>>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>>> and will continue to release, updates in sync with the PostgreSQL
>>>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>>>> has also kept up with the Beta releases for PostgreSQL 11.
>>>>
>>>
>>> The first issue that I can see (or more correctly, not see), is the
>>> source code. All packages on these pages need to be 100% Open Source,
>>> including the code required to build the packages themselves (but not
>>> necessarily the tools/compilers of course). Where can the code be found?
>>>
>>
>> In fact, I'd like to take this opportunity to suggest another
>> restructure. (which I've been thinking about for a while, but this makes it
>> more current)
>>
>> I think for the distribution specific ones, we should really only keep
>> the community provided or recommended ones. That means on debian/ubuntu
>> pages we keep only apt.pg.org and "included in distro". For
>> redhat/ubuntu we keep only yum.pg.org and "included in distro". That
>> goes for all the platforms that we have clear recommendations on.
>>
>> The other installers, including this new one from 2ndquadrant, gets moved
>> to "3rd party distributions" on /download/,
>> which may now possibly need a sub-page with all of them on. (Incidentally,
>> this is where 2UDA already is).
>>
>
> I could go with that.
>
>
> +1. Happy to draft up a patch with some screenshots to demonstrate
> what this would look like.
>
>
>
>>
>> The remaining question then becomes Windows and Mac. My personal view is
>> keep the EDB installer on the Windows one, but consider keeping
>> postgres.app instead on Mac (along with references to things like homebrew)
>> as that seems to resonate with what people actually want on that platform.
>> But I'm not a Mac user myself, so somebody who is might have an argument
>> for keeping others there instead.
>>
>
> Postgres.app has a very different design goal than the other Mac packages;
> I think we need both options there. I'd also note that some of the
> back-branch versions of Postgres.app are quite out of date which is a
> problem in of itself.
>
> (and FWIW, I still think that Homebrew should be removed and cast into a
> pit of fire for the futzing it does with permissions/ownership of
> /usr/local/)
>
>
> If you could reword this with “Homebrew has demonstrative issues that could
> affect the security of running PostgreSQL on OSX/MacOS” perhaps we could
> drop it in this release, or add language “We don’t recommend installing
> PostgreSQL
> with Homebrew because of blah blah blah.”
>
> That said, I’d like to confirm that is still true prior to making that
> decision.
>

I did;

*==>** The following existing directories will be made group writable:*

/usr/local/bin

/usr/local/lib

/usr/local/share

/usr/local/var

*==>** The following existing directories will have their owner set to *
*dpage*:

/usr/local/bin

/usr/local/lib

/usr/local/share

/usr/local/var

*==>** The following existing directories will have their group set to *
*admin*:

/usr/local/bin

/usr/local/lib

/usr/local/share

/usr/local/var

I would rather we don't list a distro, than list one that we have to put
security warnings against.

>
> The idea ehind ghit is, of course, to simplify things for our users. Right
>> now we quite honestly provide more options than they need. It's good to
>> have those, but it's also good to have a very straight forward path for
>> those who don't have any non-standard needs. Each page can be given a
>> "there are also a number of third party options available, <click here> to
>> see them".
>>
>>
>> Finally; "PGInstaller" is the name used by the original Windows packaging
>>> that Magnus and I used to maintain (http://pgfoundry.org/projects
>>> /pginstaller/). I for one would appreciate it if you didn't use that
>>> name, but came up with something original.
>>>
>>>
>> +1. (And for the record, I still get mailman spam for pginstaller now and
>> then :P So while we may think it's dead, it's definitely playing zombie now
>> and then)
>>
>
> …I feel like that should go in a “fun fact” section somewhere on the site.
> Wiki? :-)
>
> Jonathan
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2018-08-28 13:39, Dave Page wrote:
<snip>
> I did;
>
> *==>** The following existing directories will be made group writable:*
>
> /usr/local/bin
>
> /usr/local/lib
>
> /usr/local/share
>
> /usr/local/var
>
> *==>** The following existing directories will have their owner set to
> *
> *dpage*:
>
> /usr/local/bin
>
> /usr/local/lib
>
> /usr/local/share
>
> /usr/local/var
>
> *==>** The following existing directories will have their group set to
> *
> *admin*:
>
> /usr/local/bin
>
> /usr/local/lib
>
> /usr/local/share
>
> /usr/local/var
>
> I would rather we don't list a distro, than list one that we have to
> put
> security warnings against.

Isn't OSX/macOS considered a "single user" system for the vast majority
of its users?

Note - I'm meaning "single person has access to the machine", rather
than talking about the process separation model.

For a single user machine, the above setup doesn't seem terrible. It's
not giving world writeable access, it's just claiming ownership of
otherwise unused directories for the main users group.

?

Anyone using OSX/macOS in multi-user fashion is probably going to hit
other issues too (eg other people's apps in /Applications), and probably
:) avoids Homebrew.

+ Justin

On Tue, Aug 28, 2018 at 2:31 PM, Justin Clift <justin(at)postgresql(dot)org> wrote:

> On 2018-08-28 13:39, Dave Page wrote:
> <snip>
>
>> I did;
>>
>> *==>** The following existing directories will be made group writable:*
>>
>> /usr/local/bin
>>
>> /usr/local/lib
>>
>> /usr/local/share
>>
>> /usr/local/var
>>
>> *==>** The following existing directories will have their owner set to *
>> *dpage*:
>>
>> /usr/local/bin
>>
>> /usr/local/lib
>>
>> /usr/local/share
>>
>> /usr/local/var
>>
>> *==>** The following existing directories will have their group set to *
>> *admin*:
>>
>> /usr/local/bin
>>
>> /usr/local/lib
>>
>> /usr/local/share
>>
>> /usr/local/var
>>
>> I would rather we don't list a distro, than list one that we have to put
>> security warnings against.
>>
>
> Isn't OSX/macOS considered a "single user" system for the vast majority of
> its users?
>
> Note - I'm meaning "single person has access to the machine", rather than
> talking about the process separation model.
>
> For a single user machine, the above setup doesn't seem terrible. It's
> not giving world writeable access, it's just claiming ownership of
> otherwise unused directories for the main users group.
>
> ?
>
> Anyone using OSX/macOS in multi-user fashion is probably going to hit
> other issues too (eg other people's apps in /Applications), and probably :)
> avoids Homebrew.

I have multiple shared Macs. I've never run into such an issue, probably
because you need root permissions to install something in /Applications
rather than ~/Applications.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Aug 28, 2018 at 1:50 PM, Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
wrote:

>
>
> On Tue, Aug 28, 2018 at 4:11 PM Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
>
>> On Tue, Aug 28, 2018 at 1:01 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>
>> Thanks, Dave, for picking that one up. I had it on my list to deal with
>> but it somehow slipped out of my inbox.
>>
>>
>> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <
>>> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find attached a patch to add PGInstaller to the Downloads
>>>> section of postgresql.org.
>>>>
>>>> PGInstaller offers an easy way to install PostgreSQL. We have found
>>>> this to be crucial to our customers who are used to GUI-based,
>>>> click-n-point installers on Windows and at times on macOS. PGInstaller has
>>>> evolved from 2UDA, a package that 2ndQuadrant has been working on for more
>>>> than 3 years.
>>>>
>>>> 2ndQuadrant is committed to developing and actively maintaining
>>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>>> and will continue to release, updates in sync with the PostgreSQL
>>>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>>>> has also kept up with the Beta releases for PostgreSQL 11.
>>>>
>>>
>>> The first issue that I can see (or more correctly, not see), is the
>>> source code. All packages on these pages need to be 100% Open Source,
>>> including the code required to build the packages themselves (but not
>>> necessarily the tools/compilers of course). Where can the code be found?
>>>
>>
>> In fact, I'd like to take this opportunity to suggest another
>> restructure. (which I've been thinking about for a while, but this makes it
>> more current)
>>
>> I think for the distribution specific ones, we should really only keep
>> the community provided or recommended ones. That means on debian/ubuntu
>> pages we keep only apt.pg.org and "included in distro". For
>> redhat/ubuntu we keep only yum.pg.org and "included in distro". That
>> goes for all the platforms that we have clear recommendations on.
>>
>> The other installers, including this new one from 2ndquadrant, gets moved
>> to "3rd party distributions" on /download/,
>> which may now possibly need a sub-page with all of them on. (Incidentally,
>> this is where 2UDA already is).
>>
>> The remaining question then becomes Windows and Mac. My personal view is
>> keep the EDB installer on the Windows one, but consider keeping
>> postgres.app instead on Mac (along with references to things like homebrew)
>> as that seems to resonate with what people actually want on that platform.
>> But I'm not a Mac user myself, so somebody who is might have an argument
>> for keeping others there instead.
>>
>
> I can understand keeping PGDG's apt and yum repositories as the community
> provided/recommended sources for distribution specific ones. I am not sure
> I understand the reasoning behind the Windows suggestion though. Are you
> proposing that the community starts recommending the use of EDB installers
> for Windows?
>

The community has been doing that for years, on account of it being listed
at the top of the page.

My main suggestion is that there should be *one* clear recommendation.
Whether it's the EDB one or another one is a separate discussion, but we've
been recommending the EDB one for a long time and none of our users have
(AFAIK) complained about it (except when download servers have been down.
Personally I'd really like to see the binaries hosted on the postgresql.org
servers instead, but again that's an at least partially separate
discussion).

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

> On Aug 28, 2018, at 1:06 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
>
>
> On Tue, Aug 28, 2018 at 1:50 PM, Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com <mailto:umair(dot)shahid(at)2ndquadrant(dot)com>> wrote:
>
>
> On Tue, Aug 28, 2018 at 4:11 PM Magnus Hagander <magnus(at)hagander(dot)net <mailto:magnus(at)hagander(dot)net>> wrote:
> On Tue, Aug 28, 2018 at 1:01 PM, Dave Page <dpage(at)pgadmin(dot)org <mailto:dpage(at)pgadmin(dot)org>> wrote:
> Hi
>
> Thanks, Dave, for picking that one up. I had it on my list to deal with but it somehow slipped out of my inbox.
>
>
> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com <mailto:umair(dot)shahid(at)2ndquadrant(dot)com>>wrote:
> Hi,
>
> Please find attached a patch to add PGInstaller to the Downloads section of postgresql.org <http://postgresql.org/>.
>
> PGInstaller offers an easy way to install PostgreSQL. We have found this to be crucial to our customers who are used to GUI-based, click-n-point installers on Windows and at times on macOS. PGInstaller has evolved from 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>
> 2ndQuadrant is committed to developing and actively maintaining PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing, and will continue to release, updates in sync with the PostgreSQL community, most recently announcing the minor release on 9-Aug. PGInstaller has also kept up with the Beta releases for PostgreSQL 11.
>
> The first issue that I can see (or more correctly, not see), is the source code. All packages on these pages need to be 100% Open Source, including the code required to build the packages themselves (but not necessarily the tools/compilers of course). Where can the code be found?
>
> In fact, I'd like to take this opportunity to suggest another restructure. (which I've been thinking about for a while, but this makes it more current)
>
> I think for the distribution specific ones, we should really only keep the community provided or recommended ones. That means on debian/ubuntu pages we keep only apt.pg.org <http://apt.pg.org/> and "included in distro". For redhat/ubuntu we keep only yum.pg.org <http://yum.pg.org/> and "included in distro". That goes for all the platforms that we have clear recommendations on.
>
> The other installers, including this new one from 2ndquadrant, gets moved to "3rd party distributions" on /download/ </download/>, which may now possibly need a sub-page with all of them on. (Incidentally, this is where 2UDA already is).
>
> The remaining question then becomes Windows and Mac. My personal view is keep the EDB installer on the Windows one, but consider keeping postgres.app instead on Mac (along with references to things like homebrew) as that seems to resonate with what people actually want on that platform. But I'm not a Mac user myself, so somebody who is might have an argument for keeping others there instead.
>
> I can understand keeping PGDG's apt and yum repositories as the community provided/recommended sources for distribution specific ones. I am not sure I understand the reasoning behind the Windows suggestion though. Are you proposing that the community starts recommending the use of EDB installers for Windows?
>
> The community has been doing that for years, on account of it being listed at the top of the page.
>
> My main suggestion is that there should be *one* clear recommendation.

+1. Definitely a much better user experience.

> Whether it's the EDB one or another one is a separate discussion, but we've been recommending the EDB one for a long time and none of our users have (AFAIK) complained about it (except when download servers have been down. Personally I'd really like to see the binaries hosted on the postgresql.org <http://postgresql.org/> servers instead, but again that's an at least partially separate discussion).

Partially separate discussion, but probably a separate discussion. However,
since you opened it up, I would say +1 for it, but I understand there are
additional considerations the infrastructure needs to make around hosting
that, in addition to “which installer is chosen.”

However, it does make selecting “3rd party installers” much clearer if we
have one recommended installer that the community maintains and hosts
and then a section with other installers that may have add-ons, etc.

Jonathan

On Tue, Aug 28, 2018 at 01:19:28PM -0400, Jonathan Katz wrote:
> On Aug 28, 2018, at 1:06 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Whether it's the EDB one or another one is a separate discussion, but we've
> been recommending the EDB one for a long time and none of our users have
> (AFAIK) complained about it (except when download servers have been down.
> Personally I'd really like to see the binaries hosted on the postgresql.org
> servers instead, but again that's an at least partially separate
> discussion).
>
> Partially separate discussion, but probably a separate discussion. However,
> since you opened it up, I would say +1 for it, but I understand there are
> additional considerations the infrastructure needs to make around hosting
> that, in addition to “which installer is chosen.”

Well, if we have another installer provider who has similar or better
performance for things we care about, e.g. reliable updates, support,
_and_ is willing to host the binaries where we want them, we can switch
to them. While it is kind of disloyal to change preferred providers, we
also didn't agree to have them be preferred forever, especially if
someone better shows up. Of course, switching might be disruptive for
our installers uses, so we have to consider that too.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

On 2018-08-28 18:32, Bruce Momjian wrote:
> On Tue, Aug 28, 2018 at 01:19:28PM -0400, Jonathan Katz wrote:
>> On Aug 28, 2018, at 1:06 PM, Magnus Hagander <magnus(at)hagander(dot)net>
>> wrote:
>> Whether it's the EDB one or another one is a separate discussion,
>> but we've
>> been recommending the EDB one for a long time and none of our
>> users have
>> (AFAIK) complained about it (except when download servers have
>> been down.
>> Personally I'd really like to see the binaries hosted on the
>> postgresql.org
>> servers instead, but again that's an at least partially separate
>> discussion).
>>
>> Partially separate discussion, but probably a separate discussion.
>> However,
>> since you opened it up, I would say +1 for it, but I understand there
>> are
>> additional considerations the infrastructure needs to make around
>> hosting
>> that, in addition to “which installer is chosen.”
>
> Well, if we have another installer provider who has similar or better
> performance for things we care about, e.g. reliable updates, support,
> _and_ is willing to host the binaries where we want them, we can switch
> to them. While it is kind of disloyal to change preferred providers,
> we
> also didn't agree to have them be preferred forever, especially if
> someone better shows up. Of course, switching might be disruptive for
> our installers uses, so we have to consider that too.

An alternative approach would be for us ("the project") to build
official
installers ourselves, with those being the recommended ones.

Whether it be 100% volunteer based, someone we hire (several people have
pointed out we're not short of funds), or whatever. Just from the
"neutral
third party" (not vendor owned) perspective. ;)

+ Justin

On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
> On 2018-08-28 18:32, Bruce Momjian wrote:
> >Well, if we have another installer provider who has similar or better
> >performance for things we care about, e.g. reliable updates, support,
> >_and_ is willing to host the binaries where we want them, we can switch
> >to them. While it is kind of disloyal to change preferred providers, we
> >also didn't agree to have them be preferred forever, especially if
> >someone better shows up. Of course, switching might be disruptive for
> >our installers uses, so we have to consider that too.
>
> An alternative approach would be for us ("the project") to build official
> installers ourselves, with those being the recommended ones.

Uh, we used to do that but found the user support overhead too much.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

On 2018-08-28 20:06, Bruce Momjian wrote:
> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
>> On 2018-08-28 18:32, Bruce Momjian wrote:
>> >Well, if we have another installer provider who has similar or better
>> >performance for things we care about, e.g. reliable updates, support,
>> >_and_ is willing to host the binaries where we want them, we can switch
>> >to them. While it is kind of disloyal to change preferred providers, we
>> >also didn't agree to have them be preferred forever, especially if
>> >someone better shows up. Of course, switching might be disruptive for
>> >our installers uses, so we have to consider that too.
>>
>> An alternative approach would be for us ("the project") to build
>> official
>> installers ourselves, with those being the recommended ones.
>
> Uh, we used to do that but found the user support overhead too much.

No worries, was just a thought. :)

+ Justin

On 8/28/18 3:15 PM, Justin Clift wrote:
> On 2018-08-28 20:06, Bruce Momjian wrote:
>> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
>>> On 2018-08-28 18:32, Bruce Momjian wrote:
>>> >Well, if we have another installer provider who has similar or better
>>> >performance for things we care about, e.g. reliable updates, support,
>>> >_and_ is willing to host the binaries where we want them, we can
>>> switch
>>> >to them.  While it is kind of disloyal to change preferred
>>> providers, we
>>> >also didn't agree to have them be preferred forever, especially if
>>> >someone better shows up.  Of course, switching might be disruptive for
>>> >our installers uses, so we have to consider that too.
>>>
>>> An alternative approach would be for us ("the project") to build
>>> official
>>> installers ourselves, with those being the recommended ones.
>>
>> Uh, we used to do that but found the user support overhead too much.
>
> No worries, was just a thought. :)

Well, a few things has changed since the decision was made, such as
tools, resources, and in some cases, people, so we do have a good
opportunity to reevaluate and see what makes sense. The success of the
yum + apt repositories also provides a template for how to manage &
support the installers.

I do understand it is a bit more involved (i.e. there are interface
components with a lot of these) but perhaps we can do what the other
packages do and install the minimum for supporting a PostgreSQL environment.

Jonathan

On Tue, Aug 28, 2018 at 03:22:25PM -0400, Jonathan Katz wrote:
> On 8/28/18 3:15 PM, Justin Clift wrote:
> > On 2018-08-28 20:06, Bruce Momjian wrote:
> >> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
> >>> On 2018-08-28 18:32, Bruce Momjian wrote:
> >>> >Well, if we have another installer provider who has similar or better
> >>> >performance for things we care about, e.g. reliable updates, support,
> >>> >_and_ is willing to host the binaries where we want them, we can
> >>> switch
> >>> >to them.  While it is kind of disloyal to change preferred
> >>> providers, we
> >>> >also didn't agree to have them be preferred forever, especially if
> >>> >someone better shows up.  Of course, switching might be disruptive for
> >>> >our installers uses, so we have to consider that too.
> >>>
> >>> An alternative approach would be for us ("the project") to build
> >>> official
> >>> installers ourselves, with those being the recommended ones.
> >>
> >> Uh, we used to do that but found the user support overhead too much.
> >
> > No worries, was just a thought. :)
>
> Well, a few things has changed since the decision was made, such as
> tools, resources, and in some cases, people, so we do have a good
> opportunity to reevaluate and see what makes sense. The success of the
> yum + apt repositories also provides a template for how to manage &
> support the installers.
>
> I do understand it is a bit more involved (i.e. there are interface
> components with a lot of these) but perhaps we can do what the other
> packages do and install the minimum for supporting a PostgreSQL environment.

Sure, we can certainly reevaluate. The biggest user support load, as I
remember, was Windows users.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

> On Aug 28, 2018, at 12:01 PM, Justin Clift <justin(at)postgresql(dot)org> wrote:
>
> On 2018-08-28 18:32, Bruce Momjian wrote:
>> On Tue, Aug 28, 2018 at 01:19:28PM -0400, Jonathan Katz wrote:
>>> On Aug 28, 2018, at 1:06 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> Whether it's the EDB one or another one is a separate discussion, but we've
>>> been recommending the EDB one for a long time and none of our users have
>>> (AFAIK) complained about it (except when download servers have been down.
>>> Personally I'd really like to see the binaries hosted on the postgresql.org
>>> servers instead, but again that's an at least partially separate
>>> discussion).
>>> Partially separate discussion, but probably a separate discussion. However,
>>> since you opened it up, I would say +1 for it, but I understand there are
>>> additional considerations the infrastructure needs to make around hosting
>>> that, in addition to “which installer is chosen.”
>> Well, if we have another installer provider who has similar or better
>> performance for things we care about, e.g. reliable updates, support,
>> _and_ is willing to host the binaries where we want them, we can switch
>> to them. While it is kind of disloyal to change preferred providers, we
>> also didn't agree to have them be preferred forever, especially if
>> someone better shows up. Of course, switching might be disruptive for
>> our installers uses, so we have to consider that too.
>
> An alternative approach would be for us ("the project") to build official
> installers ourselves, with those being the recommended ones.

That would make sense if the PGDG installers were the "best" for
some definition of such. That seems like it'd be the place to start if
we wanted to make them the preferred ones.

In the macOS world there are a wider variety of PostgreSQL installers,
with different focuses (good for development, good for production, similar
to a unix install) and they're all useful.

> Whether it be 100% volunteer based, someone we hire (several people have
> pointed out we're not short of funds), or whatever. Just from the "neutral
> third party" (not vendor owned) perspective. ;)

If "we" wanted to put together a Windows installer it might be nice to start
with a smaller project to see what installer toolchain (e.g. wix) we wanted to
use, and what features we wanted to support.

A fairly regular request from Windows users is an installer for just the client
binaries - psql, libpq etc.. That would be a useful product in itself, as well
as a good proof of concept.

That's probably diving way off topic for -www though.

Cheers,
Steve

On Tue, Aug 28, 2018 at 9:06 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
> > On 2018-08-28 18:32, Bruce Momjian wrote:
> > >Well, if we have another installer provider who has similar or better
> > >performance for things we care about, e.g. reliable updates, support,
> > >_and_ is willing to host the binaries where we want them, we can switch
> > >to them. While it is kind of disloyal to change preferred providers, we
> > >also didn't agree to have them be preferred forever, especially if
> > >someone better shows up. Of course, switching might be disruptive for
> > >our installers uses, so we have to consider that too.
> >
> > An alternative approach would be for us ("the project") to build official
> > installers ourselves, with those being the recommended ones.
>
> Uh, we used to do that but found the user support overhead too much.
>
>
No, that's not the reason. The user support overhead doesn't change between
installers TBH. That changed because the new ones are simply more adapted
to user needs.

It was the maintenance burden of them that was simply too terrible. Now,
that's better today with more modern tools, but it's still not trivial. So
the first thing we'd need if we want to change that back into being
community maintained would be volunteers to do the actual work. I'm all for
having it volunteer based like we have with apt or yum for example, but
that needs to start with people willing to do the work.

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

On 2018-08-29 06:49, Magnus Hagander wrote:
> On Tue, Aug 28, 2018 at 9:06 PM, Bruce Momjian <bruce(at)momjian(dot)us>
> wrote:
>> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
>> > On 2018-08-28 18:32, Bruce Momjian wrote:
>> > >Well, if we have another installer provider who has similar or better
>> > >performance for things we care about, e.g. reliable updates, support,
>> > >_and_ is willing to host the binaries where we want them, we can switch
>> > >to them. While it is kind of disloyal to change preferred providers, we
>> > >also didn't agree to have them be preferred forever, especially if
>> > >someone better shows up. Of course, switching might be disruptive for
>> > >our installers uses, so we have to consider that too.
>> >
>> > An alternative approach would be for us ("the project") to build official
>> > installers ourselves, with those being the recommended ones.
>>
>> Uh, we used to do that but found the user support overhead too much.
>>
> No, that's not the reason. The user support overhead doesn't change
> between
> installers TBH. That changed because the new ones are simply more
> adapted
> to user needs.
>
> It was the maintenance burden of them that was simply too terrible.
> Now,
> that's better today with more modern tools, but it's still not trivial.
> So
> the first thing we'd need if we want to change that back into being
> community maintained would be volunteers to do the actual work. I'm all
> for
> having it volunteer based like we have with apt or yum for example, but
> that needs to start with people willing to do the work.

+1

On Tue, Aug 28, 2018 at 8:22 PM, Jonathan S. Katz <jkatz(at)postgresql(dot)org>
wrote:

> On 8/28/18 3:15 PM, Justin Clift wrote:
> > On 2018-08-28 20:06, Bruce Momjian wrote:
> >> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
> >>> On 2018-08-28 18:32, Bruce Momjian wrote:
> >>> >Well, if we have another installer provider who has similar or better
> >>> >performance for things we care about, e.g. reliable updates, support,
> >>> >_and_ is willing to host the binaries where we want them, we can
> >>> switch
> >>> >to them. While it is kind of disloyal to change preferred
> >>> providers, we
> >>> >also didn't agree to have them be preferred forever, especially if
> >>> >someone better shows up. Of course, switching might be disruptive for
> >>> >our installers uses, so we have to consider that too.
> >>>
> >>> An alternative approach would be for us ("the project") to build
> >>> official
> >>> installers ourselves, with those being the recommended ones.
> >>
> >> Uh, we used to do that but found the user support overhead too much.
> >
> > No worries, was just a thought. :)
>
> Well, a few things has changed since the decision was made, such as
> tools, resources, and in some cases, people, so we do have a good
> opportunity to reevaluate and see what makes sense. The success of the
> yum + apt repositories also provides a template for how to manage &
> support the installers.
>
> I do understand it is a bit more involved (i.e. there are interface
> components with a lot of these) but perhaps we can do what the other
> packages do and install the minimum for supporting a PostgreSQL
> environment.
>

You're missing a ton of history here. PostgreSQL (many, many years ago)
used to get a *lot* of negative reactions because it was hard to install an
environment that was complete and ready to go, with GUI etc as Windows/Mac
users typically expect - in comparison to MySQL which had that nailed.

The original PGInstaller project fixed that for Windows, by bundling PG,
pgAdmin and a bunch of other things together. Unfortunately it was an
absolute PITA to maintain.

We (various -core folks) agreed with EDB that they would build new
installers covering all platforms. These were designed to be much easier to
maintain, and added StackBuilder to ease that further by de-coupling many
of the components, whilst at the same time continuing to make it much
easier for people to add to their installations.

After some years we managed to get the RPM/DEB packaging and download flow
much more simplified, to the point that that route is easy (and preferred)
for Linux users. FYI, the EDB installers for Linux are no longer being
produced for 11.x onwards.

On Windows and Mac the EDB (and equivalent installers from other folks) are
still produced and will likely continue to be. First and foremost of
course, because they make it very easy to install and get up and running.
That of course, needs to remain the primary focus; and simplifying any
packages to a minimum will be a major step backwards.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

> On Aug 29, 2018, at 4:20 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>
>
> On Tue, Aug 28, 2018 at 8:22 PM, Jonathan S. Katz <jkatz(at)postgresql(dot)org <mailto:jkatz(at)postgresql(dot)org>> wrote:
> On 8/28/18 3:15 PM, Justin Clift wrote:
> > On 2018-08-28 20:06, Bruce Momjian wrote:
> >> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
> >>> On 2018-08-28 18:32, Bruce Momjian wrote:
> >>> >Well, if we have another installer provider who has similar or better
> >>> >performance for things we care about, e.g. reliable updates, support,
> >>> >_and_ is willing to host the binaries where we want them, we can
> >>> switch
> >>> >to them. While it is kind of disloyal to change preferred
> >>> providers, we
> >>> >also didn't agree to have them be preferred forever, especially if
> >>> >someone better shows up. Of course, switching might be disruptive for
> >>> >our installers uses, so we have to consider that too.
> >>>
> >>> An alternative approach would be for us ("the project") to build
> >>> official
> >>> installers ourselves, with those being the recommended ones.
> >>
> >> Uh, we used to do that but found the user support overhead too much.
> >
> > No worries, was just a thought. :)
>
> Well, a few things has changed since the decision was made, such as
> tools, resources, and in some cases, people, so we do have a good
> opportunity to reevaluate and see what makes sense. The success of the
> yum + apt repositories also provides a template for how to manage &
> support the installers.
>
> I do understand it is a bit more involved (i.e. there are interface
> components with a lot of these) but perhaps we can do what the other
> packages do and install the minimum for supporting a PostgreSQL environment.
>
> You're missing a ton of history here.

Thank you for filling in some of the missing pieces for me!

> PostgreSQL (many, many years ago) used to get a *lot* of negative reactions because it was hard to install an environment that was complete and ready to go, with GUI etc as Windows/Mac users typically expect - in comparison to MySQL which had that nailed.

I for one will say that back in that day, I did fall into the “had a challenge
installing” camp, but from it I learned how to build from source.

> The original PGInstaller project fixed that for Windows, by bundling PG, pgAdmin and a bunch of other things together. Unfortunately it was an absolute PITA to maintain.
>
> We (various -core folks) agreed with EDB that they would build new installers covering all platforms. These were designed to be much easier to maintain, and added StackBuilder to ease that further by de-coupling many of the components, whilst at the same time continuing to make it much easier for people to add to their installations.
>
> After some years we managed to get the RPM/DEB packaging and download flow much more simplified, to the point that that route is easy (and preferred) for Linux users. FYI, the EDB installers for Linux are no longer being produced for 11.x onwards.

Which sounds like we will need to make some updates to the Linux
download pages (or the lack of updates?) ;-)

> On Windows and Mac the EDB (and equivalent installers from other folks) are still produced and will likely continue to be. First and foremost of course, because they make it very easy to install and get up and running.

In fact, I have referred people to setting up PostgreSQL on their local envs
with those exact installers.

> That of course, needs to remain the primary focus; and simplifying any packages to a minimum will be a major step backwards.

With the history you presented that makes sense; primarily I was focused on trying
to find some way to help facilitate making it easier to support the installers in the
.org environment, where in this discussion, my primary focus is ensuring it’s easy
for people to download and install PostgreSQL. While I have opinions on packaging,
I defer to the people who actually have to maintain the packages as I know doing so
is a lot of work.

Anyway, to bring this full circle, I +1 Magnus’ earlier suggestions wrt the featured
installers and what goes on the 3rd Party Installations page. We could figure out
if .org wants to host its own Mac/Windows installers if someone volunteers to do
so.

Jonathan

On Tue, Aug 28, 2018 at 4:46 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
wrote:

> Hi Dave
> On Tue, Aug 28, 2018 at 4:01 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> Hi
>>
>> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <
>> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>
>>> Hi,
>>>
>>> Please find attached a patch to add PGInstaller to the Downloads section
>>> of postgresql.org.
>>>
>>> PGInstaller offers an easy way to install PostgreSQL. We have found this
>>> to be crucial to our customers who are used to GUI-based, click-n-point
>>> installers on Windows and at times on macOS. PGInstaller has evolved from
>>> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>>>
>>> 2ndQuadrant is committed to developing and actively maintaining
>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>> and will continue to release, updates in sync with the PostgreSQL
>>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>>> has also kept up with the Beta releases for PostgreSQL 11.
>>>
>>
>> The first issue that I can see (or more correctly, not see), is the
>> source code. All packages on these pages need to be 100% Open Source,
>> including the code required to build the packages themselves (but not
>> necessarily the tools/compilers of course). Where can the code be found?
>>
>
> I didn't realize that was a requirement. Let me work with the team
> internally to open the source code.
>

The source code is available here:
https://github.com/2ndQuadrant/postgres-installer

>
>
>>
>> Secondly, it looks like your ordering is not quite as it should be on
>> some pages. We list native packages first, followed by non-native, then
>> third party packaging systems, with new additions at the end of the
>> appropriate section to limit confusion for users (particularly those who
>> pick the first item then later try to upgrade it).
>>
>> E.g. on the Ubuntu page, it should be:
>>
>> PG APT Repo
>> BigSQL DEB Packages
>> EDB Installers
>> 2ndQ Installers
>>
>> On the Mac page:
>>
>> EDB Installers
>> BigSQL Installers
>> Postgres.app
>> 2ndQ Installers
>>
>> Similarly for other pages.
>>
>
> We can work on that.
>

The attached patch has the ordering as required.

>
>
>>
>> Finally; "PGInstaller" is the name used by the original Windows packaging
>> that Magnus and I used to maintain (
>> http://pgfoundry.org/projects/pginstaller/) I for one would appreciate
>> it if you didn't use that name, but came up with something original.
>>
>
> Given Magnus' email that this is not a completely dead project, I think
> that's reasonable. I'll get back on this thread with the requested changes.
>

The name has been updated to Postgres Installer.

>
>
>>
>> Thanks.
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
> --
> Umair Shahid
> Head of Marketing & Products
> 2ndQuadrant - The team of diligent PostgreSQL experts
> https://www.2ndQuadrant.com/
>

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

Hello,

while we are here, may I ask you www-guys to consider our request
/message-id/flat/311b87dc-648e-0827-9530-18855ea63785%40postgrespro.ru#7bbed328d5cf9161eabc13885729b9fb

Best regards,
Oleg

On Tue, Sep 11, 2018 at 5:26 PM, Umair Shahid
<umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>
> On Tue, Aug 28, 2018 at 4:46 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
> wrote:
>>
>> Hi Dave
>> On Tue, Aug 28, 2018 at 4:01 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>> Hi
>>>
>>> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid
>>> <umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please find attached a patch to add PGInstaller to the Downloads section
>>>> of postgresql.org.
>>>>
>>>> PGInstaller offers an easy way to install PostgreSQL. We have found this
>>>> to be crucial to our customers who are used to GUI-based, click-n-point
>>>> installers on Windows and at times on macOS. PGInstaller has evolved from
>>>> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>>>>
>>>> 2ndQuadrant is committed to developing and actively maintaining
>>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>>> and will continue to release, updates in sync with the PostgreSQL community,
>>>> most recently announcing the minor release on 9-Aug. PGInstaller has also
>>>> kept up with the Beta releases for PostgreSQL 11.
>>>
>>>
>>> The first issue that I can see (or more correctly, not see), is the
>>> source code. All packages on these pages need to be 100% Open Source,
>>> including the code required to build the packages themselves (but not
>>> necessarily the tools/compilers of course). Where can the code be found?
>>
>>
>> I didn't realize that was a requirement. Let me work with the team
>> internally to open the source code.
>
>
> The source code is available here:
> https://github.com/2ndQuadrant/postgres-installer
>
>>
>>
>>>
>>>
>>> Secondly, it looks like your ordering is not quite as it should be on
>>> some pages. We list native packages first, followed by non-native, then
>>> third party packaging systems, with new additions at the end of the
>>> appropriate section to limit confusion for users (particularly those who
>>> pick the first item then later try to upgrade it).
>>>
>>> E.g. on the Ubuntu page, it should be:
>>>
>>> PG APT Repo
>>> BigSQL DEB Packages
>>> EDB Installers
>>> 2ndQ Installers
>>>
>>> On the Mac page:
>>>
>>> EDB Installers
>>> BigSQL Installers
>>> Postgres.app
>>> 2ndQ Installers
>>>
>>> Similarly for other pages.
>>
>>
>> We can work on that.
>
>
> The attached patch has the ordering as required.
>
>>
>>
>>>
>>>
>>> Finally; "PGInstaller" is the name used by the original Windows packaging
>>> that Magnus and I used to maintain
>>> (http://pgfoundry.org/projects/pginstaller/) I for one would appreciate it
>>> if you didn't use that name, but came up with something original.
>>
>>
>> Given Magnus' email that this is not a completely dead project, I think
>> that's reasonable. I'll get back on this thread with the requested changes.
>
>
> The name has been updated to Postgres Installer.
>
>>
>>
>>>
>>>
>>> Thanks.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>
>>
>>
>> --
>> Umair Shahid
>> Head of Marketing & Products
>> 2ndQuadrant - The team of diligent PostgreSQL experts
>> https://www.2ndQuadrant.com/
>
>
>
> --
> Umair Shahid
> Head of Marketing & Products
> 2ndQuadrant - The team of diligent PostgreSQL experts
> https://www.2ndQuadrant.com/

--
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

*bump*

On Tue, Sep 11, 2018 at 7:26 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
wrote:

>
> On Tue, Aug 28, 2018 at 4:46 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
> wrote:
>
>> Hi Dave
>> On Tue, Aug 28, 2018 at 4:01 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <
>>> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find attached a patch to add PGInstaller to the Downloads
>>>> section of postgresql.org.
>>>>
>>>> PGInstaller offers an easy way to install PostgreSQL. We have found
>>>> this to be crucial to our customers who are used to GUI-based,
>>>> click-n-point installers on Windows and at times on macOS. PGInstaller has
>>>> evolved from 2UDA, a package that 2ndQuadrant has been working on for more
>>>> than 3 years.
>>>>
>>>> 2ndQuadrant is committed to developing and actively maintaining
>>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>>> and will continue to release, updates in sync with the PostgreSQL
>>>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>>>> has also kept up with the Beta releases for PostgreSQL 11.
>>>>
>>>
>>> The first issue that I can see (or more correctly, not see), is the
>>> source code. All packages on these pages need to be 100% Open Source,
>>> including the code required to build the packages themselves (but not
>>> necessarily the tools/compilers of course). Where can the code be found?
>>>
>>
>> I didn't realize that was a requirement. Let me work with the team
>> internally to open the source code.
>>
>
> The source code is available here:
> https://github.com/2ndQuadrant/postgres-installer
>
>
>>
>>
>>>
>>> Secondly, it looks like your ordering is not quite as it should be on
>>> some pages. We list native packages first, followed by non-native, then
>>> third party packaging systems, with new additions at the end of the
>>> appropriate section to limit confusion for users (particularly those who
>>> pick the first item then later try to upgrade it).
>>>
>>> E.g. on the Ubuntu page, it should be:
>>>
>>> PG APT Repo
>>> BigSQL DEB Packages
>>> EDB Installers
>>> 2ndQ Installers
>>>
>>> On the Mac page:
>>>
>>> EDB Installers
>>> BigSQL Installers
>>> Postgres.app
>>> 2ndQ Installers
>>>
>>> Similarly for other pages.
>>>
>>
>> We can work on that.
>>
>
> The attached patch has the ordering as required.
>
>
>>
>>
>>>
>>> Finally; "PGInstaller" is the name used by the original Windows
>>> packaging that Magnus and I used to maintain (
>>> http://pgfoundry.org/projects/pginstaller/) I for one would appreciate
>>> it if you didn't use that name, but came up with something original.
>>>
>>
>> Given Magnus' email that this is not a completely dead project, I think
>> that's reasonable. I'll get back on this thread with the requested changes.
>>
>
> The name has been updated to Postgres Installer.
>
>
>>
>>
>>>
>>> Thanks.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>> --
>> Umair Shahid
>> Head of Marketing & Products
>> 2ndQuadrant - The team of diligent PostgreSQL experts
>> https://www.2ndQuadrant.com/
>>
>
>
> --
> Umair Shahid
> Head of Marketing & Products
> 2ndQuadrant - The team of diligent PostgreSQL experts
> https://www.2ndQuadrant.com/
>

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

On Tue, Sep 11, 2018 at 7:26 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
wrote:

>
> On Tue, Aug 28, 2018 at 4:46 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
> wrote:
>
>> Hi Dave
>> On Tue, Aug 28, 2018 at 4:01 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <
>>> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find attached a patch to add PGInstaller to the Downloads
>>>> section of postgresql.org.
>>>>
>>>> PGInstaller offers an easy way to install PostgreSQL. We have found
>>>> this to be crucial to our customers who are used to GUI-based,
>>>> click-n-point installers on Windows and at times on macOS. PGInstaller has
>>>> evolved from 2UDA, a package that 2ndQuadrant has been working on for more
>>>> than 3 years.
>>>>
>>>> 2ndQuadrant is committed to developing and actively maintaining
>>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>>> and will continue to release, updates in sync with the PostgreSQL
>>>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>>>> has also kept up with the Beta releases for PostgreSQL 11.
>>>>
>>>
>>> The first issue that I can see (or more correctly, not see), is the
>>> source code. All packages on these pages need to be 100% Open Source,
>>> including the code required to build the packages themselves (but not
>>> necessarily the tools/compilers of course). Where can the code be found?
>>>
>>
>> I didn't realize that was a requirement. Let me work with the team
>> internally to open the source code.
>>
>
> The source code is available here:
> https://github.com/2ndQuadrant/postgres-installer
>
>
>>
>>
>>>
>>> Secondly, it looks like your ordering is not quite as it should be on
>>> some pages. We list native packages first, followed by non-native, then
>>> third party packaging systems, with new additions at the end of the
>>> appropriate section to limit confusion for users (particularly those who
>>> pick the first item then later try to upgrade it).
>>>
>>> E.g. on the Ubuntu page, it should be:
>>>
>>> PG APT Repo
>>> BigSQL DEB Packages
>>> EDB Installers
>>> 2ndQ Installers
>>>
>>> On the Mac page:
>>>
>>> EDB Installers
>>> BigSQL Installers
>>> Postgres.app
>>> 2ndQ Installers
>>>
>>> Similarly for other pages.
>>>
>>
>> We can work on that.
>>
>
> The attached patch has the ordering as required.
>

As requested, we have updated the patch, renamed the installer, and opened
up the source code. Kindly consider our revised patch. I am attaching it
here again for reference.

>
>
>>
>>
>>>
>>> Finally; "PGInstaller" is the name used by the original Windows
>>> packaging that Magnus and I used to maintain (
>>> http://pgfoundry.org/projects/pginstaller/) I for one would appreciate
>>> it if you didn't use that name, but came up with something original.
>>>
>>
>> Given Magnus' email that this is not a completely dead project, I think
>> that's reasonable. I'll get back on this thread with the requested changes.
>>
>
> The name has been updated to Postgres Installer.
>
>
>>
>>
>>>
>>> Thanks.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>> --
>> Umair Shahid
>> Head of Marketing & Products
>> 2ndQuadrant - The team of diligent PostgreSQL experts
>> https://www.2ndQuadrant.com/
>>
>
>
> --
> Umair Shahid
> Head of Marketing & Products
> 2ndQuadrant - The team of diligent PostgreSQL experts
> https://www.2ndQuadrant.com/
>

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

On Thu, Sep 27, 2018 at 4:49 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
wrote:

>
>
> On Tue, Sep 11, 2018 at 7:26 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
> wrote:
>
>>
>> On Tue, Aug 28, 2018 at 4:46 PM Umair Shahid <
>> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>
>>> Hi Dave
>>> On Tue, Aug 28, 2018 at 4:01 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>> Hi
>>>>
>>>> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid <
>>>> umair(dot)shahid(at)2ndquadrant(dot)com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Please find attached a patch to add PGInstaller to the Downloads
>>>>> section of postgresql.org.
>>>>>
>>>>> PGInstaller offers an easy way to install PostgreSQL. We have found
>>>>> this to be crucial to our customers who are used to GUI-based,
>>>>> click-n-point installers on Windows and at times on macOS. PGInstaller has
>>>>> evolved from 2UDA, a package that 2ndQuadrant has been working on for more
>>>>> than 3 years.
>>>>>
>>>>> 2ndQuadrant is committed to developing and actively maintaining
>>>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>>>> and will continue to release, updates in sync with the PostgreSQL
>>>>> community, most recently announcing the minor release on 9-Aug. PGInstaller
>>>>> has also kept up with the Beta releases for PostgreSQL 11.
>>>>>
>>>>
>>>> The first issue that I can see (or more correctly, not see), is the
>>>> source code. All packages on these pages need to be 100% Open Source,
>>>> including the code required to build the packages themselves (but not
>>>> necessarily the tools/compilers of course). Where can the code be found?
>>>>
>>>
>>> I didn't realize that was a requirement. Let me work with the team
>>> internally to open the source code.
>>>
>>
>> The source code is available here:
>> https://github.com/2ndQuadrant/postgres-installer
>>
>>
>>>
>>>
>>>>
>>>> Secondly, it looks like your ordering is not quite as it should be on
>>>> some pages. We list native packages first, followed by non-native, then
>>>> third party packaging systems, with new additions at the end of the
>>>> appropriate section to limit confusion for users (particularly those who
>>>> pick the first item then later try to upgrade it).
>>>>
>>>> E.g. on the Ubuntu page, it should be:
>>>>
>>>> PG APT Repo
>>>> BigSQL DEB Packages
>>>> EDB Installers
>>>> 2ndQ Installers
>>>>
>>>> On the Mac page:
>>>>
>>>> EDB Installers
>>>> BigSQL Installers
>>>> Postgres.app
>>>> 2ndQ Installers
>>>>
>>>> Similarly for other pages.
>>>>
>>>
>>> We can work on that.
>>>
>>
>> The attached patch has the ordering as required.
>>
>
> As requested, we have updated the patch, renamed the installer, and opened
> up the source code. Kindly consider our revised patch. I am attaching it
> here again for reference.
>

Hi. Any updates on this?

If there is specific feedback on how to make this patch better, please let
me know. Thanks!

>
>
>>
>>
>>>
>>>
>>>>
>>>> Finally; "PGInstaller" is the name used by the original Windows
>>>> packaging that Magnus and I used to maintain (
>>>> http://pgfoundry.org/projects/pginstaller/) I for one would
>>>> appreciate it if you didn't use that name, but came up with something
>>>> original.
>>>>
>>>
>>> Given Magnus' email that this is not a completely dead project, I think
>>> that's reasonable. I'll get back on this thread with the requested changes.
>>>
>>
>> The name has been updated to Postgres Installer.
>>
>>
>>>
>>>
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Dave Page
>>>> Blog: http://pgsnake.blogspot.com
>>>> Twitter: @pgsnake
>>>>
>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>> The Enterprise PostgreSQL Company
>>>>
>>>
>>>
>>> --
>>> Umair Shahid
>>> Head of Marketing & Products
>>> 2ndQuadrant - The team of diligent PostgreSQL experts
>>> https://www.2ndQuadrant.com/
>>>
>>
>>
>> --
>> Umair Shahid
>> Head of Marketing & Products
>> 2ndQuadrant - The team of diligent PostgreSQL experts
>> https://www.2ndQuadrant.com/
>>
>
>
> --
> Umair Shahid
> Head of Marketing & Products
> 2ndQuadrant - The team of diligent PostgreSQL experts
> https://www.2ndQuadrant.com/
>

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

Hi,

On 10/8/18 9:11 AM, Umair Shahid wrote:
>
>
> Hi. Any updates on this? 
>
> If there is specific feedback on how to make this patch better, please
> let me know. Thanks!
We're sorry this is taking some time to get to - with the major release
and some other larger pgweb projects, in addition to some of the
discussion on how to set this up, we have not been able to prioritize
it. We will get to this in the weeks after the PG11 launch.

Our plan is to focus on doing some restructuring on the downloads page -
which there appears to be consensus - before adding additional
installers. Getting this done will allow us to add the installers
shortly, if not immediately, after.

Thanks!

Jonathan

On Sat, Oct 13, 2018 at 04:20:42PM -0400, Jonathan Katz wrote:
> Hi,
>
> On 10/8/18 9:11 AM, Umair Shahid wrote:
> >
> >
> > Hi. Any updates on this? 
> >
> > If there is specific feedback on how to make this patch better, please
> > let me know. Thanks!
> We're sorry this is taking some time to get to - with the major release
> and some other larger pgweb projects, in addition to some of the
> discussion on how to set this up, we have not been able to prioritize
> it. We will get to this in the weeks after the PG11 launch.
>
> Our plan is to focus on doing some restructuring on the downloads page -
> which there appears to be consensus - before adding additional
> installers. Getting this done will allow us to add the installers
> shortly, if not immediately, after.

Considering that Postgres Pro has been waiting almost a year, and 2nd
Quadrant a month, I am thinking we need to resolve this soon.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

On Sun, Oct 14, 2018 at 1:20 AM Jonathan S. Katz <jkatz(at)postgresql(dot)org>
wrote:

> Hi,
>
> On 10/8/18 9:11 AM, Umair Shahid wrote:
> >
> >
> > Hi. Any updates on this?
> >
> > If there is specific feedback on how to make this patch better, please
> > let me know. Thanks!
> We're sorry this is taking some time to get to - with the major release
> and some other larger pgweb projects, in addition to some of the
> discussion on how to set this up, we have not been able to prioritize
> it. We will get to this in the weeks after the PG11 launch.
>
> Our plan is to focus on doing some restructuring on the downloads page -
> which there appears to be consensus - before adding additional
> installers. Getting this done will allow us to add the installers
> shortly, if not immediately, after.
>

Thank you for the explanation Jonathan, though I am not sure I quite get
it. The Downloads page needs restructuring, which apparently needs to be
done regardless of whether Postgres Installer is listed there. I don't
understand why Postgres Installer should be held up because of it.

We moved quickly to address all concerns raised in the first round. It
sends a rather discouraging message from the community if I find out about
this decision more than a month after I sent the revised patch, and that
too after repeated reminders.

I believe this puts Postgres Installer at a disadvantage, and without good
reason. I would urge you to kindly reconsider. Thanks!

>
> Thanks!
>
> Jonathan
>
>

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

On Tue, Oct 16, 2018 at 8:13 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
wrote:

>
>
> On Sun, Oct 14, 2018 at 1:20 AM Jonathan S. Katz <jkatz(at)postgresql(dot)org>
> wrote:
>
>> Hi,
>>
>> On 10/8/18 9:11 AM, Umair Shahid wrote:
>> >
>> >
>> > Hi. Any updates on this?
>> >
>> > If there is specific feedback on how to make this patch better, please
>> > let me know. Thanks!
>> We're sorry this is taking some time to get to - with the major release
>> and some other larger pgweb projects, in addition to some of the
>> discussion on how to set this up, we have not been able to prioritize
>> it. We will get to this in the weeks after the PG11 launch.
>>
>> Our plan is to focus on doing some restructuring on the downloads page -
>> which there appears to be consensus - before adding additional
>> installers. Getting this done will allow us to add the installers
>> shortly, if not immediately, after.
>>
>
> Thank you for the explanation Jonathan, though I am not sure I quite get
> it. The Downloads page needs restructuring, which apparently needs to be
> done regardless of whether Postgres Installer is listed there. I don't
> understand why Postgres Installer should be held up because of it.
>
> We moved quickly to address all concerns raised in the first round. It
> sends a rather discouraging message from the community if I find out about
> this decision more than a month after I sent the revised patch, and that
> too after repeated reminders.
>
> I believe this puts Postgres Installer at a disadvantage, and without good
> reason. I would urge you to kindly reconsider. Thanks!
>
>

Hi!

It's not about putting any of the installers at an advantage or at a
disadvantage. It is whether we put our *users* at an advantage or a
disadvantage, and the consensus on that is pretty clear -- we are not doing
our users any service by having a whole bunch of different installers on
the same page without a clear and working structure. And yes, adding more
options without structure and clearness to the end user on which should be
used for what, will be of negative value. What we have now does not
"scale", and piling more on it just makes it work.

Thus, we need to work on that structure first. Unfortunately, there seems
to be a distinct lack of people willing to work on *that* part, so it takes
longer.

It is definitely true that you have worked quickly to address the problems
that were there with the patch initially, and that is definitely
appreciated. But just like with PostgreSQL itself, that's no guarantee that
it will get in.

It's just like the main PostgreSQL sourcecode -- we don't apply patches
even though the author updates them quickly based on comments if it's
determined that they are counterproductive to the bigger goal of the
product. It's the same here, just for the website.

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

On Wed, Oct 17, 2018 at 1:17 AM Magnus Hagander <magnus(at)hagander(dot)net> wrote:

> On Tue, Oct 16, 2018 at 8:13 PM Umair Shahid <umair(dot)shahid(at)2ndquadrant(dot)com>
> wrote:
>
>>
>>
>> On Sun, Oct 14, 2018 at 1:20 AM Jonathan S. Katz <jkatz(at)postgresql(dot)org>
>> wrote:
>>
>>> Hi,
>>>
>>> On 10/8/18 9:11 AM, Umair Shahid wrote:
>>> >
>>> >
>>> > Hi. Any updates on this?
>>> >
>>> > If there is specific feedback on how to make this patch better, please
>>> > let me know. Thanks!
>>> We're sorry this is taking some time to get to - with the major release
>>> and some other larger pgweb projects, in addition to some of the
>>> discussion on how to set this up, we have not been able to prioritize
>>> it. We will get to this in the weeks after the PG11 launch.
>>>
>>> Our plan is to focus on doing some restructuring on the downloads page -
>>> which there appears to be consensus - before adding additional
>>> installers. Getting this done will allow us to add the installers
>>> shortly, if not immediately, after.
>>>
>>
>> Thank you for the explanation Jonathan, though I am not sure I quite get
>> it. The Downloads page needs restructuring, which apparently needs to be
>> done regardless of whether Postgres Installer is listed there. I don't
>> understand why Postgres Installer should be held up because of it.
>>
>> We moved quickly to address all concerns raised in the first round. It
>> sends a rather discouraging message from the community if I find out about
>> this decision more than a month after I sent the revised patch, and that
>> too after repeated reminders.
>>
>> I believe this puts Postgres Installer at a disadvantage, and without
>> good reason. I would urge you to kindly reconsider. Thanks!
>>
>>
>
> Hi!
>
> It's not about putting any of the installers at an advantage or at a
> disadvantage. It is whether we put our *users* at an advantage or a
> disadvantage, and the consensus on that is pretty clear -- we are not doing
> our users any service by having a whole bunch of different installers on
> the same page without a clear and working structure. And yes, adding more
> options without structure and clearness to the end user on which should be
> used for what, will be of negative value. What we have now does not
> "scale", and piling more on it just makes it work.
>
> Thus, we need to work on that structure first. Unfortunately, there seems
> to be a distinct lack of people willing to work on *that* part, so it takes
> longer.
>

Thank you Magnus. I am happy to volunteer to work on this, just need
guidance on what needs to be done. Do we have a structure finalized? I saw
some suggestions, but didn't see consensus.

>
> It is definitely true that you have worked quickly to address the problems
> that were there with the patch initially, and that is definitely
> appreciated. But just like with PostgreSQL itself, that's no guarantee that
> it will get in.
>
> It's just like the main PostgreSQL sourcecode -- we don't apply patches
> even though the author updates them quickly based on comments if it's
> determined that they are counterproductive to the bigger goal of the
> product. It's the same here, just for the website.
>
> --
> Magnus Hagander
> Me: https://www.hagander.net/ <http://www.hagander.net/>
> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
>

--
Umair Shahid
Head of Marketing & Products
2ndQuadrant - The team of diligent PostgreSQL experts
https://www.2ndQuadrant.com/

Hi,

On 10/17/18 2:36 AM, Umair Shahid wrote:
>
>
> On Wed, Oct 17, 2018 at 1:17 AM Magnus Hagander <magnus(at)hagander(dot)net
> <mailto:magnus(at)hagander(dot)net>> wrote:

> It is definitely true that you have worked quickly to address the
> problems that were there with the patch initially, and that is
> definitely appreciated. But just like with PostgreSQL itself, that's
> no guarantee that it will get in.
>
> It's just like the main PostgreSQL sourcecode -- we don't apply
> patches even though the author updates them quickly based on
> comments if it's determined that they are counterproductive to the
> bigger goal of the product. It's the same here, just for the website.

Given some other flurry on -www this week with patches, I want to write
in to say that this thread has not been forgotten. Based on various
discussions on-list, off-list, and at PGConf.EU, designing a patch
(likely patch set) for this will take some work and will most certainly
require review and discussion.

I went to make an initial attempt while at PGConf.EU and saw the design
scope would be a bit more complicated than one would think to ensure
it's clear for our users how to download the packages. I am hoping to
have something more concrete to share after the upcoming cumulative update.

Thanks,

Jonathan

On Tue, Nov 6, 2018 at 12:52 AM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>
> Hi,
>
> On 10/17/18 2:36 AM, Umair Shahid wrote:
> >
> >
> > On Wed, Oct 17, 2018 at 1:17 AM Magnus Hagander <magnus(at)hagander(dot)net
> > <mailto:magnus(at)hagander(dot)net>> wrote:
>
> > It is definitely true that you have worked quickly to address the
> > problems that were there with the patch initially, and that is
> > definitely appreciated. But just like with PostgreSQL itself, that's
> > no guarantee that it will get in.
> >
> > It's just like the main PostgreSQL sourcecode -- we don't apply
> > patches even though the author updates them quickly based on
> > comments if it's determined that they are counterproductive to the
> > bigger goal of the product. It's the same here, just for the website.
>
> Given some other flurry on -www this week with patches, I want to write
> in to say that this thread has not been forgotten. Based on various
> discussions on-list, off-list, and at PGConf.EU, designing a patch
> (likely patch set) for this will take some work and will most certainly
> require review and discussion.
>
> I went to make an initial attempt while at PGConf.EU and saw the design
> scope would be a bit more complicated than one would think to ensure
> it's clear for our users how to download the packages. I am hoping to
> have something more concrete to share after the upcoming cumulative update.

Trying to revive this thread. My personal interest is to have link
from download page to our windows installer
https://postgrespro.com/windows. There was already discussion what we
should have on this page and what's not, so I don't understand the
problem of updating that page.

>
> Thanks,
>
> Jonathan
>

--
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company