Thread: Patch abstracts in the Commitfest app
While reading through and working with the hundreds of patches in the CF app a small feature/process request struck me: it would be really helpful if the patch had a brief abstract outlining what it aims to add or fix (or summary, description or something else; not sure what to call it). Basically a two-sentence or so version of the email posting the patch to -hackers. The "title" field isn't always explanatory enough, and diving into a long thread to piece together clues can be quite daunting. I'm especially thinking about new contributors who would like to contribute but who have a hard time finding something in the CF app (which is a complaint I've heard from multiple such contributors). It should be a free-form textfield, and only apply to new submissions to avoid a need to backfill. The field should, IMHO, be mandatory. The implementation can be left to discussion on -www iff this list agrees that it would be a good thing. Thoughts? -- Daniel Gustafsson https://vmware.com/
On Fri, Nov 12, 2021 at 8:51 PM Daniel Gustafsson <daniel@yesql.se> wrote: > > While reading through and working with the hundreds of patches in the CF app a > small feature/process request struck me: it would be really helpful if the > patch had a brief abstract outlining what it aims to add or fix (or summary, > description or something else; not sure what to call it). Basically a > two-sentence or so version of the email posting the patch to -hackers. > > The "title" field isn't always explanatory enough, and diving into a long > thread to piece together clues can be quite daunting. I'm especially thinking > about new contributors who would like to contribute but who have a hard time > finding something in the CF app (which is a complaint I've heard from multiple > such contributors). > > It should be a free-form textfield, and only apply to new submissions to avoid > a need to backfill. The field should, IMHO, be mandatory. The implementation > can be left to discussion on -www iff this list agrees that it would be a good > thing. +1 for the idea. Not sure if that should be mandatory though, as some simple entries should be self explanatory. Really this is mainly helpful for long and lengthy threads, when people start to ask a summary of the situation, so it should be editable and maybe automatically generates an email on the thread when that happens.
On Fri, Nov 12, 2021 at 01:51:28PM +0100, Daniel Gustafsson wrote: > While reading through and working with the hundreds of patches in the CF app a > small feature/process request struck me: it would be really helpful if the > patch had a brief abstract outlining what it aims to add or fix (or summary, > description or something else; not sure what to call it). Basically a > two-sentence or so version of the email posting the patch to -hackers. This seems fine ; that purpose is partially served (and duplicated) by the patch commit messages (if used). Actually, it's already possible to add an "annotation" to a given message-id. I've just added this here: https://commitfest.postgresql.org/35/2800/ I think this that feature is rarely used, but I can see the value in using it more, for long threads. If you really wanted to make an "abstract" not associated with any message-id, I think it would be implemented simply by removing the restriction that an message-id must be specified and must match an existing message in the thead. -- Justin
> On 12 Nov 2021, at 15:24, Justin Pryzby <pryzby@telsasoft.com> wrote: > > On Fri, Nov 12, 2021 at 01:51:28PM +0100, Daniel Gustafsson wrote: >> While reading through and working with the hundreds of patches in the CF app a >> small feature/process request struck me: it would be really helpful if the >> patch had a brief abstract outlining what it aims to add or fix (or summary, >> description or something else; not sure what to call it). Basically a >> two-sentence or so version of the email posting the patch to -hackers. > > This seems fine ; that purpose is partially served (and duplicated) by the > patch commit messages (if used). That's the problem, many patches are in diff format and don't have commit messages at all. There are also many entries with patchsets containing multiple patches and thus commitmessages but the app will only link to one. > Actually, it's already possible to add an "annotation" to a given message-id. > I've just added this here: https://commitfest.postgresql.org/35/2800/ > > I think this that feature is rarely used, but I can see the value in using it > more, for long threads. I consider this feature very valuable, but I don't see it as a replacement for a text field Abstract in the patch entry. -- Daniel Gustafsson https://vmware.com/
On 11/12/21, 4:53 AM, "Daniel Gustafsson" <daniel@yesql.se> wrote: > While reading through and working with the hundreds of patches in the CF app a > small feature/process request struck me: it would be really helpful if the > patch had a brief abstract outlining what it aims to add or fix (or summary, > description or something else; not sure what to call it). Basically a > two-sentence or so version of the email posting the patch to -hackers. +1 Nathan
Julien Rouhaud <rjuju123@gmail.com> writes:
> On Fri, Nov 12, 2021 at 8:51 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>> It should be a free-form textfield, and only apply to new submissions to avoid
>> a need to backfill. The field should, IMHO, be mandatory. The implementation
>> can be left to discussion on -www iff this list agrees that it would be a good
>> thing.
> +1 for the idea. Not sure if that should be mandatory though, as some
> simple entries should be self explanatory.
Yeah, there are plenty of entries for which the title seems adequate.
No objection to making room for an additional optional description,
though.
> Really this is mainly
> helpful for long and lengthy threads, when people start to ask a
> summary of the situation, so it should be editable and maybe
> automatically generates an email on the thread when that happens.
Editable certainly, but I don't think we want any auto-generated mail.
regards, tom lane
On 11/12/21 7:51 AM, Daniel Gustafsson wrote: > > It should be a free-form textfield, and only apply to new submissions to avoid > a need to backfill. The field should, IMHO, be mandatory. The implementation > can be left to discussion on -www iff this list agrees that it would be a good > thing. +1. The patch title is often not enough to tell what the patch does, and patches also change over time. The abstract may also be helpful to the committer when generating a commit message. Regards, -- -David david@pgmasters.net