Re: Commitfest app vs. pgsql-docs - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Commitfest app vs. pgsql-docs
Date
Msg-id 9620b93f-7995-3e5d-77b4-3cad82b5af81@dunslane.net
Whole thread Raw
In response to Re: Commitfest app vs. pgsql-docs  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Commitfest app vs. pgsql-docs
List pgsql-hackers
On 5/24/21 8:42 AM, Daniel Gustafsson wrote:
>> On 24 May 2021, at 11:47, Magnus Hagander <magnus@hagander.net> wrote:
>>
>> On Wed, May 19, 2021 at 11:08 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>>> On 2021-May-19, Andrew Dunstan wrote:
>>>
>>>> It's just a reference after all. So someone supplies a reference to an
>>>> email on an out of the way list. What's the evil that will occur? Not
>>>> much really  AFAICT.
>> Well, if you include all lists, the ability for you to findi things by
>> the "most recent posts" or by searching for anything other than a
>> unique message id will likely become less useful.
> Thats a good case for restricting this to the smaller set of lists which will
> cover most submissions anyways.  With a smaller set we could make the UX still
> work without presenting an incredibly long list.
>
> Or, the most recent emails dropdown only cover a set of common lists but
> a search will scan all lists?
>
>> As long as you only ever search by message-id it won't make a difference.
> Without any supporting evidence to back it up, my gut feeling tells me the most
> recent mails list is a good/simple way to lower the bar for submissions.
>

Maybe. I only ever do this by using an exact message-id, since that's
what the web form specifically asks for :-)


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: rand48 replacement
Next
From: Nitin Jadhav
Date:
Subject: Re: Removed extra memory allocations from create_list_bounds