Thread: PG 15 downloads
Hi, I saw the following comment https://news.ycombinator.com/item?id=33194755 > Just some feedback for releases of any software: I think apt sources and > repositories should be ready to go on launch and PR-release so people can > immediately use the new version. Looks like that's going to take 2-3 > days. Sources are available but that's not something most people want to > delve in with make files and dependencies. Something like postgres is > huge. Right now, if you go to downloads and expect postgresql-15 available, > it is not; lot of people on IRC and elsewhere on Twitter are confused where > to download postgresql-15. I know that takes time, so the PR release should > just be delayed until apt sources are ready. May be also docker > repositories. Some of these are actually ready, our website does make it look like that's not the case. The pages for the EDB installers https://www.postgresql.org/download/macosx/ https://www.postgresql.org/download/windows/ only list versions up to 14, but the downloads are actually available on the EDB page. Unfortunately it does look like our debian / ubuntu packages are still at 15 rc2. Greetings, Andres Freund
Re: Andres Freund > Hi, > > I saw the following comment https://news.ycombinator.com/item?id=33194755 > > Just some feedback for releases of any software: I think apt sources and > > repositories should be ready to go on launch and PR-release so people can > > immediately use the new version. Looks like that's going to take 2-3 > > days. Sources are available but that's not something most people want to > > delve in with make files and dependencies. Something like postgres is > > huge. Right now, if you go to downloads and expect postgresql-15 available, > > it is not; lot of people on IRC and elsewhere on Twitter are confused where > > to download postgresql-15. I know that takes time, so the PR release should > > just be delayed until apt sources are ready. May be also docker > > repositories. Hi, I've been asking for some way to be able to stop syncing the apt repo from the repository master host so I can prepare the release, and then have the release people grab it from there. But that was never implemented, so things still rely on me being available to synchronously do the required steps, which is obviously not optimal. > Unfortunately it does look like our debian / ubuntu packages are still at 15 > rc2. I wasn't around yesterday, so I'm preparing the 15.0 packages now. Will take an hour from now or so. Christoph
On Thu, 13 Oct 2022 at 21:33, Andres Freund <andres@anarazel.de> wrote:
Hi,
I saw the following comment https://news.ycombinator.com/item?id=33194755
> Just some feedback for releases of any software: I think apt sources and
> repositories should be ready to go on launch and PR-release so people can
> immediately use the new version. Looks like that's going to take 2-3
> days. Sources are available but that's not something most people want to
> delve in with make files and dependencies. Something like postgres is
> huge. Right now, if you go to downloads and expect postgresql-15 available,
> it is not; lot of people on IRC and elsewhere on Twitter are confused where
> to download postgresql-15. I know that takes time, so the PR release should
> just be delayed until apt sources are ready. May be also docker
> repositories.
Some of these are actually ready, our website does make it look like that's
not the case.
The pages for the EDB installers
https://www.postgresql.org/download/macosx/
https://www.postgresql.org/download/windows/
only list versions up to 14, but the downloads are actually available on the
EDB page.
Hmm, somehow we always forget to update those pages. I think in part it's because there's currently no check/confirmation that packages are ready before the release is pushed to the website (largely for historical reasons); everyone just works to get their part done by 2PM UK time. Couple that with the fact that none of the team within EDB who work on the installers have any knowledge of the PostgreSQL website code (bar me, but I'm not involved in the day to day work these days).
1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the release push, but that would require confirmation from Sandeep or someone on the EDB team that the packages have been published and everything looks good.
--
2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interface at the appropriate time. He does have access to a limited part of the admin interface already.
In any case, I've fixed the pages now.
Thanks.
> On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org> wrote: > A couple of possible solutions that spring to mind: > > 1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the release push,but that would require confirmation from Sandeep or someone on the EDB team that the packages have been published andeverything looks good. > > 2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interfaceat the appropriate time. He does have access to a limited part of the admin interface already. 3) EDB publish an API endpoint with the available releases that pg.org consumes and use to create the page? -- Daniel Gustafsson https://vmware.com/
Hi
On Fri, 14 Oct 2022 at 10:14, Christoph Berg <myon@debian.org> wrote:
Re: Andres Freund
> Hi,
>
> I saw the following comment https://news.ycombinator.com/item?id=33194755
> > Just some feedback for releases of any software: I think apt sources and
> > repositories should be ready to go on launch and PR-release so people can
> > immediately use the new version. Looks like that's going to take 2-3
> > days. Sources are available but that's not something most people want to
> > delve in with make files and dependencies. Something like postgres is
> > huge. Right now, if you go to downloads and expect postgresql-15 available,
> > it is not; lot of people on IRC and elsewhere on Twitter are confused where
> > to download postgresql-15. I know that takes time, so the PR release should
> > just be delayed until apt sources are ready. May be also docker
> > repositories.
Hi,
I've been asking for some way to be able to stop syncing the apt repo
from the repository master host so I can prepare the release, and then
have the release people grab it from there. But that was never
implemented, so things still rely on me being available to
synchronously do the required steps, which is obviously not optimal.
Yeah, unfortunately that's not entirely straightforward to implement.
Devrim handles this problem with an email to the sysadmin team, who can disable and later re-enable yum sync. It's a minor PITA, but it works.
> Unfortunately it does look like our debian / ubuntu packages are still at 15
> rc2.
I wasn't around yesterday, so I'm preparing the 15.0 packages now.
Will take an hour from now or so.
Christoph
On Mon, 17 Oct 2022 at 09:32, Daniel Gustafsson <daniel@yesql.se> wrote:
> On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org> wrote:
> A couple of possible solutions that spring to mind:
>
> 1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the release push, but that would require confirmation from Sandeep or someone on the EDB team that the packages have been published and everything looks good.
>
> 2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interface at the appropriate time. He does have access to a limited part of the admin interface already.
3) EDB publish an API endpoint with the available releases that pg.org consumes
and use to create the page?
That could also work, though I suspect it might be less than easy for me to get someone on the right team to build that any time soon.
On Mon, Oct 17, 2022 at 10:40 AM Dave Page <dpage@pgadmin.org> wrote:
On Mon, 17 Oct 2022 at 09:32, Daniel Gustafsson <daniel@yesql.se> wrote:> On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org> wrote:
> A couple of possible solutions that spring to mind:
>
> 1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the release push, but that would require confirmation from Sandeep or someone on the EDB team that the packages have been published and everything looks good.
>
> 2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interface at the appropriate time. He does have access to a limited part of the admin interface already.
3) EDB publish an API endpoint with the available releases that pg.org consumes
and use to create the page?That could also work, though I suspect it might be less than easy for me to get someone on the right team to build that any time soon.
Doesn't have to be an API of course. Just a static json file for example, which we could import at regular intervals. Similar to how we get the data for the yum and apt repos for example, just pulling it in somewhere else. We wouldn't want to poll something all the time and do it "live", just sync up at regular intervals.
Re: Dave Page > > I've been asking for some way to be able to stop syncing the apt repo > > from the repository master host so I can prepare the release, and then > > have the release people grab it from there. But that was never > > implemented, so things still rely on me being available to > > synchronously do the required steps, which is obviously not optimal. > > > > Yeah, unfortunately that's not entirely straightforward to implement. I haven't seen the sync cronjob, but I assume it's something like rsync over ssh, so wouldn't just prepending something like this work? ssh atalia test -f /srv/apt/SYNC && rsync ... I'd then remove the SYNC file during release time. Christoph
On Mon, 17 Oct 2022 at 13:02, Christoph Berg <myon@debian.org> wrote:
Re: Dave Page
> > I've been asking for some way to be able to stop syncing the apt repo
> > from the repository master host so I can prepare the release, and then
> > have the release people grab it from there. But that was never
> > implemented, so things still rely on me being available to
> > synchronously do the required steps, which is obviously not optimal.
> >
>
> Yeah, unfortunately that's not entirely straightforward to implement.
I haven't seen the sync cronjob, but I assume it's something like
rsync over ssh, so wouldn't just prepending something like this work?
ssh atalia test -f /srv/apt/SYNC && rsync ...
I'd then remove the SYNC file during release time.
Unfortunately not (entirely). It pulls from atalia and a number of other boxes, performs a little magic, and then asynchronously pushes everything to the frontends.
On Mon, 17 Oct 2022 at 13:47, Bernardo Generoso <generoso.bernardoapple@gmail.com> wrote:
Why I’m receiving the this emails?
Because you are subscribed to the pgsql-www@lists.postgresql.org mailing list.
On 17 Oct 2022, at 13:08, Dave Page <dpage@pgadmin.org> wrote:On Mon, 17 Oct 2022 at 13:02, Christoph Berg <myon@debian.org> wrote:Re: Dave Page
> > I've been asking for some way to be able to stop syncing the apt repo
> > from the repository master host so I can prepare the release, and then
> > have the release people grab it from there. But that was never
> > implemented, so things still rely on me being available to
> > synchronously do the required steps, which is obviously not optimal.
> >
>
> Yeah, unfortunately that's not entirely straightforward to implement.
I haven't seen the sync cronjob, but I assume it's something like
rsync over ssh, so wouldn't just prepending something like this work?
ssh atalia test -f /srv/apt/SYNC && rsync ...
I'd then remove the SYNC file during release time.Unfortunately not (entirely). It pulls from atalia and a number of other boxes, performs a little magic, and then asynchronously pushes everything to the frontends.--
On 10/17/22 7:03 AM, Magnus Hagander wrote: > > > On Mon, Oct 17, 2022 at 10:40 AM Dave Page <dpage@pgadmin.org > <mailto:dpage@pgadmin.org>> wrote: > > > > On Mon, 17 Oct 2022 at 09:32, Daniel Gustafsson <daniel@yesql.se > <mailto:daniel@yesql.se>> wrote: > > > On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org > <mailto:dpage@pgadmin.org>> wrote: > > > A couple of possible solutions that spring to mind: > > > > 1) Jonathan (or whoever is handling the release process) > could ensure those pages are updated as part of the release > push, but that would require confirmation from Sandeep or > someone on the EDB team that the packages have been published > and everything looks good. FWIW, before the release I do a general sweep of the entire website to update content. The challenge with the downloads page is what's been stated a few times, i.e. it's in an indeterminate state until everyone confirms that the packages are ready. Also, the release coordinator does post to -packagers providing guidance on the release date. An interim manual step would be for a packager to reply when the packages are ready for a major release (and I can also repeatedly ping the list). I can then ensure the content is updated on the website for GA. > > 2) We could database-ise the data in those tables, and then > Sandeep could update that through the Django admin interface at > the appropriate time. He does have access to a limited part of > the admin interface already. We have this in effect already, s/database/update the website/. I think it just adds a nicer interface to how we'd update the website. So +0 on this. > 3) EDB publish an API endpoint with the available releases that > pg.org <http://pg.org> consumes > and use to create the page? > > > That could also work, though I suspect it might be less than easy > for me to get someone on the right team to build that any time soon. > > > Doesn't have to be an API of course. Just a static json file for > example, which we could import at regular intervals. Similar to how we > get the data for the yum and apt repos for example, just pulling it in > somewhere else. We wouldn't want to poll something all the time and do > it "live", just sync up at regular intervals. I'm OK with this approach. Thanks, Jonathan
Attachment
Hi, On 2022-10-17 10:32:30 +0200, Daniel Gustafsson wrote: > > On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org> wrote: > > > A couple of possible solutions that spring to mind: > > > > 1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the releasepush, but that would require confirmation from Sandeep or someone on the EDB team that the packages have been publishedand everything looks good. > > > > 2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interfaceat the appropriate time. He does have access to a limited part of the admin interface already. > > 3) EDB publish an API endpoint with the available releases that pg.org consumes > and use to create the page? Could these tables be updated well ahead of time and PG $next just be hidden until the release based on the version number? I also wonder if we should just display a row without details if data for $next hasn't been entered... Greetings, Andres Freund
On 10/17/22 11:48 AM, Andres Freund wrote: > Hi, > > On 2022-10-17 10:32:30 +0200, Daniel Gustafsson wrote: >>> On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org> wrote: >> >>> A couple of possible solutions that spring to mind: >>> >>> 1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the releasepush, but that would require confirmation from Sandeep or someone on the EDB team that the packages have been publishedand everything looks good. >>> >>> 2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interfaceat the appropriate time. He does have access to a limited part of the admin interface already. >> >> 3) EDB publish an API endpoint with the available releases that pg.org consumes >> and use to create the page? > > Could these tables be updated well ahead of time and PG $next just be hidden > until the release based on the version number? Yes, but the suggested JSON file approach accomplishes something similar, and is a pattern we already have for some of the other package repos. Thanks, Jonathan
Attachment
On Mon, 17 Oct 2022 at 16:51, Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 10/17/22 11:48 AM, Andres Freund wrote:
> Hi,
>
> On 2022-10-17 10:32:30 +0200, Daniel Gustafsson wrote:
>>> On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org> wrote:
>>
>>> A couple of possible solutions that spring to mind:
>>>
>>> 1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the release push, but that would require confirmation from Sandeep or someone on the EDB team that the packages have been published and everything looks good.
>>>
>>> 2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interface at the appropriate time. He does have access to a limited part of the admin interface already.
>>
>> 3) EDB publish an API endpoint with the available releases that pg.org consumes
>> and use to create the page?
>
> Could these tables be updated well ahead of time and PG $next just be hidden
> until the release based on the version number?
Yes, but the suggested JSON file approach accomplishes something
similar, and is a pattern we already have for some of the other package
repos.
Yeah - the problem is that I no longer manage the folks responsible for our website (and neither does Sandeep). EDB is rapidly approaching 1000 people, and that complicates this sort of thing somewhat. I do know some of the team though, and will see if I can whisper in the right ears.
On Mon, Oct 17, 2022 at 5:55 PM Dave Page <dpage@pgadmin.org> wrote:
On Mon, 17 Oct 2022 at 16:51, Jonathan S. Katz <jkatz@postgresql.org> wrote:On 10/17/22 11:48 AM, Andres Freund wrote:
> Hi,
>
> On 2022-10-17 10:32:30 +0200, Daniel Gustafsson wrote:
>>> On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org> wrote:
>>
>>> A couple of possible solutions that spring to mind:
>>>
>>> 1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the release push, but that would require confirmation from Sandeep or someone on the EDB team that the packages have been published and everything looks good.
>>>
>>> 2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interface at the appropriate time. He does have access to a limited part of the admin interface already.
>>
>> 3) EDB publish an API endpoint with the available releases that pg.org consumes
>> and use to create the page?
>
> Could these tables be updated well ahead of time and PG $next just be hidden
> until the release based on the version number?
Yes, but the suggested JSON file approach accomplishes something
similar, and is a pattern we already have for some of the other package
repos.Yeah - the problem is that I no longer manage the folks responsible for our website (and neither does Sandeep). EDB is rapidly approaching 1000 people, and that complicates this sort of thing somewhat. I do know some of the team though, and will see if I can whisper in the right ears.
Regardless of who is managing them, surely the person in charge of it should be on this list to be able to answer questions etc. And I'm sure they have the technical skills to publish a json file even without your oversight :)
On Mon, 17 Oct 2022 at 17:18, Magnus Hagander <magnus@hagander.net> wrote:
On Mon, Oct 17, 2022 at 5:55 PM Dave Page <dpage@pgadmin.org> wrote:On Mon, 17 Oct 2022 at 16:51, Jonathan S. Katz <jkatz@postgresql.org> wrote:On 10/17/22 11:48 AM, Andres Freund wrote:
> Hi,
>
> On 2022-10-17 10:32:30 +0200, Daniel Gustafsson wrote:
>>> On 17 Oct 2022, at 10:29, Dave Page <dpage@pgadmin.org> wrote:
>>
>>> A couple of possible solutions that spring to mind:
>>>
>>> 1) Jonathan (or whoever is handling the release process) could ensure those pages are updated as part of the release push, but that would require confirmation from Sandeep or someone on the EDB team that the packages have been published and everything looks good.
>>>
>>> 2) We could database-ise the data in those tables, and then Sandeep could update that through the Django admin interface at the appropriate time. He does have access to a limited part of the admin interface already.
>>
>> 3) EDB publish an API endpoint with the available releases that pg.org consumes
>> and use to create the page?
>
> Could these tables be updated well ahead of time and PG $next just be hidden
> until the release based on the version number?
Yes, but the suggested JSON file approach accomplishes something
similar, and is a pattern we already have for some of the other package
repos.Yeah - the problem is that I no longer manage the folks responsible for our website (and neither does Sandeep). EDB is rapidly approaching 1000 people, and that complicates this sort of thing somewhat. I do know some of the team though, and will see if I can whisper in the right ears.Regardless of who is managing them, surely the person in charge of it should be on this list to be able to answer questions etc.
You're suggesting the person in charge of the EDB website should be on this mailing list on the off-chance we decide to have a discussion about adding an API or file to the EDB site? That seems excessive, given this or anything like it has happened once in 15+ years.
And I'm sure they have the technical skills to publish a json file even without your oversight :)
As a side-note, I don't want a manually maintained JSON file. That won't actually help at all, as it would mean one of the site devs would need to get involved with releases, whereas right now it can be done by one of the content team as the download page itself is database-backed. What makes a lot more sense is to have the JSON file be automatically (or on-demand) generated from that database, which would only require a one-off effort from the devs.
On 10/18/22 01:15, Dave Page wrote: > > Regardless of who is managing them, surely the person in charge of > it should be on this list to be able to answer questions etc. > > > You're suggesting the person in charge of the EDB website should be on > this mailing list on the off-chance we decide to have a discussion about > adding an API or file to the EDB site? That seems excessive, given this > or anything like it has happened once in 15+ years. No, so they can be part of the conversation period so we don't have to wait for some intra-company communication/process to take place. > > And I'm sure they have the technical skills to publish a json file > even without your oversight :) > > > Of course they do. The question is one of prioritising the work, which > unless it's an issue with the download pages not working etc. I have > very little sway over. Th solution would be to move these downloads to the PGDG infrastructure and not have to wait on a company that makes it's money off Postgres getting around to prioritizing supporting Postgres. FYI, to be fair I also think the Apt repo not being updated on time is also bad. A release date is release date. Announcing to the world a version is available and not have it there is not good. > -- > Dave Page > Blog: https://pgsnake.blogspot.com <https://pgsnake.blogspot.com> > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com <https://www.enterprisedb.com> > -- Adrian Klaver adrian.klaver@aklaver.com
On Tue, 18 Oct 2022 at 15:15, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 10/18/22 01:15, Dave Page wrote:
>
> Regardless of who is managing them, surely the person in charge of
> it should be on this list to be able to answer questions etc.
>
>
> You're suggesting the person in charge of the EDB website should be on
> this mailing list on the off-chance we decide to have a discussion about
> adding an API or file to the EDB site? That seems excessive, given this
> or anything like it has happened once in 15+ years.
No, so they can be part of the conversation period so we don't have to
wait for some intra-company communication/process to take place.
Well on that basis, perhaps you could subscribe to the pgadmin-hackers mailing list just in case we decide we need something from you in a few years?
Yes, that's a facetious suggestion, but I don't think it's far from what's being asked.
>
> And I'm sure they have the technical skills to publish a json file
> even without your oversight :)
>
>
> Of course they do. The question is one of prioritising the work, which
> unless it's an issue with the download pages not working etc. I have
> very little sway over.
Th solution would be to move these downloads to the PGDG infrastructure
and not have to wait on a company that makes it's money off Postgres
getting around to prioritizing supporting Postgres.
There was no "getting around to prioritizing supporting Postgres". The installers were published and available on time, and the people doing that work updated everything they've ever been asked to. Moving downloads to PGDG infrastructure would not have avoided the problem being discussed at all; the pages that needed updating would still need to be updated by someone, through some mechanism that doesn't involve having commit rights on the website repo and doesn't currently exist.
On 10/18/22 07:43, Dave Page wrote: > > > On Tue, 18 Oct 2022 at 15:15, Adrian Klaver <adrian.klaver@aklaver.com > <mailto:adrian.klaver@aklaver.com>> wrote: > > On 10/18/22 01:15, Dave Page wrote: > > > > > Regardless of who is managing them, surely the person in > charge of > > it should be on this list to be able to answer questions etc. > > > > > > You're suggesting the person in charge of the EDB website should > be on > > this mailing list on the off-chance we decide to have a > discussion about > > adding an API or file to the EDB site? That seems excessive, > given this > > or anything like it has happened once in 15+ years. > > No, so they can be part of the conversation period so we don't have to > wait for some intra-company communication/process to take place. > > > Well on that basis, perhaps you could subscribe to the pgadmin-hackers > mailing list just in case we decide we need something from you in a few > years? > > Yes, that's a facetious suggestion, but I don't think it's far from > what's being asked. Except I have not interest in doing anything with pgAdmin, whereas the EDB installer maintainers do need to know what is going on with a site they are linked to. By your own admission you are not really involved with anymore, so it would seem having at least one of the folks that is involved monitoring the list would be a good idea. > There was no "getting around to prioritizing supporting Postgres". The I went back and reread the thread and realized I was mistaken, the installers where there. The Postgres site had not been updated. For that I apologize. > installers were published and available on time, and the people doing > that work updated everything they've ever been asked to. Moving > downloads to PGDG infrastructure would not have avoided the > problem being discussed at all; the pages that needed updating would > still need to be updated by someone, through some mechanism that doesn't > involve having commit rights on the website repo and doesn't currently > exist. > > -- > Dave Page > Blog: https://pgsnake.blogspot.com <https://pgsnake.blogspot.com> > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com <https://www.enterprisedb.com> > -- Adrian Klaver adrian.klaver@aklaver.com
On Tue, 18 Oct 2022 at 16:18, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 10/18/22 07:43, Dave Page wrote:
>
>
> On Tue, 18 Oct 2022 at 15:15, Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> wrote:
>
> On 10/18/22 01:15, Dave Page wrote:
>
> >
> > Regardless of who is managing them, surely the person in
> charge of
> > it should be on this list to be able to answer questions etc.
> >
> >
> > You're suggesting the person in charge of the EDB website should
> be on
> > this mailing list on the off-chance we decide to have a
> discussion about
> > adding an API or file to the EDB site? That seems excessive,
> given this
> > or anything like it has happened once in 15+ years.
>
> No, so they can be part of the conversation period so we don't have to
> wait for some intra-company communication/process to take place.
>
>
> Well on that basis, perhaps you could subscribe to the pgadmin-hackers
> mailing list just in case we decide we need something from you in a few
> years?
>
> Yes, that's a facetious suggestion, but I don't think it's far from
> what's being asked.
Except I have not interest in doing anything with pgAdmin, whereas the
EDB installer maintainers do need to know what is going on with a site
they are linked to. By your own admission you are not really involved
with anymore, so it would seem having at least one of the folks that is
involved monitoring the list would be a good idea.
I'm not involved with the EDB website team any more. I'm still involved with the installer maintainer team, albeit in a supervisory rather than practical fix-bugs-myself role. So that team does have a presence on this list.
> There was no "getting around to prioritizing supporting Postgres". The
I went back and reread the thread and realized I was mistaken, the
installers where there. The Postgres site had not been updated. For that
I apologize.
No problem, thanks.