Re: PG 15 downloads - Mailing list pgsql-www
| From | Dave Page |
|---|---|
| Subject | Re: PG 15 downloads |
| Date | |
| Msg-id | CA+OCxowNyCYjc1juWiioDrNSu5wjQXsx4=8JJxs_vWsKJm3Hww@mail.gmail.com Whole thread Raw |
| In response to | Re: PG 15 downloads (Magnus Hagander <magnus@hagander.net>) |
| Responses |
Re: PG 15 downloads
|
| List | pgsql-www |
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.