Re: Detailed release notes
| От | Euler Taveira |
|---|---|
| Тема | Re: Detailed release notes |
| Дата | |
| Msg-id | 8e5f43c4-ac1e-4085-9bd3-4c923b1b2d51@app.fastmail.com обсуждение исходный текст |
| Ответ на | Re: Detailed release notes (Daniel Gustafsson <daniel@yesql.se>) |
| Ответы |
Re: Detailed release notes
|
| Список | pgsql-hackers |
On Mon, Aug 5, 2024, at 10:33 AM, Daniel Gustafsson wrote:
On 5 Aug 2024, at 13:16, Marcos Pegoraro <marcos@f10.com.br> wrote:Em seg., 5 de ago. de 2024 às 07:54, jian he <jian.universality@gmail.com> escreveu:[commitId_link1, commitId_link2]: Change functions to use a safesearch_path during maintenance operations (Jeff Davis)I don't like that prefix dirtying each item.I too would prefer links at the end, not least since we might have 2 or 3 (ormore) links for an item.
+1.
Python also links to the Github issue and not the commit, in our project theanalog to that would be linking to the thread in the mailinglist archive aswell as the commit. For us linking to the commit is probably preferrable sinceit will link to the thread but the thread often wont link to the commit (like aGithub issue will). Maybe icons for code/emailthread can be used to make itclear what the link is, and cut down to horizontal space required?
PgBouncer adds the PR number at the end [1] too. I generally prefer this style
because you read the message and after that if you want additional detail you
can click on the link at the end.
I don't know if linking to the thread is a good idea. We have long long threads
that cannot provide quick information for the reader. Since we don't have a
concept of every commit has a CF entry, IMO we should use only commits here. The
commit message points to the discussion so it is a good start point if you want
to research about that specific feature.
If one commit is not sufficient for that item, we can always add multiple
commits as we usually do in the release notes comments.
В списке pgsql-hackers по дате отправления: