From: "Jonathan S. Katz" <jkatz@postgresql.org>
Subject: Re: BUG #15706: Support Services page out of date,Re: BUG #15706:
Support Services page out of date,Re: BUG #15706: Support Services page out of date,Re: BUG #15706: Support Services
pageout of date
Date: Sun, 28 Apr 2019 17:41:30 -0400
Message-ID: <da24e2b8-c633-90d5-0739-18bc7286ed16@postgresql.org>,<da24e2b8-c633-90d5-0739-18bc7286ed16@postgresql.org>
> Hi Tatsuo,
>
> On 4/28/19 5:38 PM, Tatsuo Ishii wrote:
>>> On 4/26/19 11:48 PM, Jonathan S. Katz wrote:
>>>> On 3/25/19 5:33 AM, Daniel Gustafsson wrote:
>>>>> On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net>
>>>>> wrote:
>>>>>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org
>>>>>> <mailto:jkatz@postgresql.org>> wrote:
>>>>>>
>>>>>> Some of the pgweb folks have discussed doing that before; it's not
>>>>>> a bad
>>>>>> idea, and perhaps would cut down on some of the headaches.
>>>>>>
>>>>>>
>>>>>> That was in fact the original plan, nobody just got around to building
>>>>>> it. There was even a db field for it in the early dev snapshots, but
>>>>>> it was removed since it was never quite done.
>>>>>>
>>>>>> The general idea was to just have a "last confirmed" timestamp field
>>>>>> on each entry, and just stop showing any entries that have not been
>>>>>> confirmed in <n> days/weeks/months/whatever. We can keep them around
>>>>>> some extra time beyond that in case people come back to update them
>>>>>> later of course.
>>>>>
>>>>> I think it makes sense to remove after a set timeout, if the user hasn't
>>>>> verified in 3 months (or some
>>>>> other sufficiently long period) then the odds that the entry is out of
>>>>> date seems quite high.
>>>>>
>>>>>> Oh, and +1 for doing the same for products.
>>>
>>> OK, so I did the scrub for products.
>>>
>>>> The scrub took me about 2 hours and change.
>>>
>>> Fortunately, products are a bit more straightforward and did not take as
>>> long as services, though it was still at least an hour. So whatever
>>> system we put in place for services, I suggest the same for products
>>>
>>> There were 210 products listed at the beginning of the scrub.
>>>
>>> - 170 remain
>>> - 40 were removed as they did not exist + no obvious replacement / went
>>> to things I wish I could unsee.
>>>
>>> I would say this was more stale than I thought too, but given that there
>>> has not been a product scrub as long as I can remember, it's not as bad
>>> as the staleness of the services.
>>>
>>> Regardless, let's work on getting that system into place to help manage
>>> it so scrubs are less gargantuan tasks.
>>
>> Are we working on this region only?
>> https://www.postgresql.org/support/professional_support/northamerica/
>
> I went through every organization that was listed, regardless of region.
>
>> Some of the companies listed in the northamerica page also appear in
>> other regions (I only checked aisa though). I think companies removed
>> from the northamerica region should also be removed from other regions
>> as well unless they explicitly stat that they have different entities
>> in the other regions.
>
> The pgweb schema allows for a professional service to be listed in all
> the regions it operates. I did not adjust that; I only removed
> organizations that were clearly no longer operating (based on above
> definition), and reached out to other orgs for clarifying questions. In
> the case of removal, the org was removed from _all_ regions.
Great! That perfectly makes sense.
BTW, how can companies listed on those pages update the descriptions?
I see new registeration form:
https://www.postgresql.org/account/services/new/
but fails to find update or removal form.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp