Re: PG 15 downloads

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