Re: Tags in the commitfest app: How to use them and what tags to add?
От | Jacob Champion |
---|---|
Тема | Re: Tags in the commitfest app: How to use them and what tags to add? |
Дата | |
Msg-id | CAOYmi+m7=JrNX3rzjTvbBJ9S6m_hjiDDEZKTL-iT+wfR33WTQw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tags in the commitfest app: How to use them and what tags to add? (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: Tags in the commitfest app: How to use them and what tags to add?
Re: Tags in the commitfest app: How to use them and what tags to add? Re: Tags in the commitfest app: How to use them and what tags to add? |
Список | pgsql-hackers |
On Mon, Jun 23, 2025 at 12:01 PM David G. Johnston <david.g.johnston@gmail.com> wrote: > > Yes, categories, and give each category its own line in the table. I'm headed in the opposite direction. Let me elaborate with some very strong opinions about the existing tags. (No one has to share my strong opinions.) - Help - Bikeshedding - Good First Review - Missing Tests This category of tag is the best. It is completely new information, not captured anywhere else in the UI, that is useful at the top level and helps drive reviews forward by helping the community find interesting things. - Bugfix - Security I'm not excited about these tags, but in the absence of a bug tracker, I'm glad we have them. Now it doesn't matter what "section" your patch is in; if you realize it needs to be treated as a bug fix, or it gains some sort of security caveat, you can tag them as such. - dblink - PL/Perl - postgres_fdw I don't like these at all. You can already search the patches with the search box, so introducing a community norm that adds a bunch of "which code did I touch" tags serves to clutter the UI and give new CFMs an excuse to spend a bunch of time categorizing as opposed to moving patches forward. Put the target of your patch in the entry title somewhere -- and if it touches ten sections, I didn't really want to see ten tags anyways. - Backport I am completely against this tag in particular. We have this information already in its own Version column (though it's kind of sad it's not sortable). If that column isn't working for people now, I really doubt that moving the information to tags is going to help in any way; we can either clarify the Version labels or make the meaning discoverable. --Jacob
В списке pgsql-hackers по дате отправления: