Thread: Bugs status tracking
*I understand the community's strong preference for maintaining the
mailing list as the primary platform for discussions. My proposal does not
aim to replace or disrupt the workflow of the mailing list. Instead, it
seeks to provide a transparent and organized way to access bug-related
data, which can be particularly helpful for new contributors or those
outside the community. Currently, there is no centralized system to track
the status of bugs, nor is there a dedicated GitHub repository for
PostgreSQL bugs, as the main Git repository does not allow issues to be
posted.
*Let me explain the workflow, and I welcome feedback and suggestions:
*--Bug as the Main Issue with Comments in Chronological Order:*
Each bug from the pgsql-bugs mailing list will be added as a main
issue in the GitHub repository, with all subsequent replies organized as
comments in chronological order.[Currently, viewing an entire discussion
requires navigating the thread link in the mailing list. This proposal
ensures that bugs and replies are always presented in an organized and
accessible manner.]
**Automatic Updates: If a new reply is logged for an
existing bug, it will be automatically added to the corresponding issue's
comments. Labels will also update dynamically. For example, if a previously
closed bug is reopened, its label will change to "Open."
*--Bug Status Identification:*
Bug status will be categorized as "Open," "Closed," or
"Unresponsive" using NLP techniques such as Sentiment Analysis, Keyword
Analysis, and Time Heuristics based on the content and tone discussed.
**Any suggestions for improvements or alternate methods for
identifying bug statuses are greatly appreciated.
*--Maintaining the Mailing List Workflow:*
This system will not serve as a discussion platform. Instead, it
maintains a systematic flow and status of bugs posted on the pgsql-bugs
mailing list in a more readable format.
**If anyone wants to discuss a bug based on the status in the
GitHub repository, they can refer to the date posted and continue the
discussion on the mailing list. Any updates from the mailing list will then
be reflected in the GitHub repository.
*As Álvaro suggested earlier, if there is a way to collaborate with the
CommitFest app or integrate this proposal with the mailing list more
directly, please share the relevant code or guidelines. Such collaboration
would be a valuable addition.
Thanks and regards,
Vasuki M
C-DAC,Chennai,India
mail: bharatdb(at)cdac(dot)in, vasukim1992002(at)gmail(dot)com
phn:+91 6374605133
Please can u tell whether it is ok or not or do we need to change anything ,as of now the community is bigger and we have people to track the status so please give suggestions or corrections.
Hi Greg,
Thank you for your response and feedback.
I have created a demo repository for tracking pgsql-bugs reports:
🔗 GitHub Repository
The goal of this repo is to provide a structured view of bug reports from the pgsql-bugs mailing list while ensuring that all discussions continue in the mailing list itself. Each GitHub issue contains details such as the subject, date, and message ID to help contributors quickly find and respond to the original thread.
I understand that this is just an initial proof of concept, and I welcome any feedback or suggestions on improving the workflow. I appreciate your advice, and I’ll iterate on this based on community input.
Looking forward to your thoughts!
Best,
Vasuki
On Mon, Feb 17, 2025 at 2:47 AM VASUKI M <vasukim1992002@gmail.com> wrote:Please can u tell whether it is ok or not or do we need to change anything ,as of now the community is bigger and we have people to track the status so please give suggestions or corrections.All of our data is public and free to use, so you are welcome to do with it what you want.I would suggest just creating a proof of concept and let's see what it looks like. Nobody is going to officially bless it beforehand. Being able to see and critique an actual workflow is invaluable.Be warned that no matter what you come up with, not everyone will be happy with it. That's the nature of things, so don't be discouraged.Cheers,Greg--
Hi Greg,
Thanks for the suggestion. I have now resolved those issues. You can check my repository here: GitHub Issues.
I would appreciate it if Tom and Alvherre could review my repository. Once they approve, I will make it the main repository and work on pushing all the pgsql-bugs data there.
Best,
Vasuki
Looks pretty good. I would suggest getting the hyperlinks sorted out. If you look at this bug for example:--The message-id has an unwanted mailto link, and the first sentence has a mangled hyperlink.The word wrapping seems aggressive as well; it would be nice to keep the original formatting and allow things to be more than 80 characters (like this sentence, which is exactly 219 characters long and has no newlines).Searching by partial message id is hit or miss. "CACTY" matches nothing, but "CACTYHzjDSgV3qZu2stgBZ" does.That's a very well-written README.md (https://github.com/Vasuki-git/mailing-lists)Cheers,Greg--Crunchy Data - https://www.crunchydata.comEnterprise Postgres Software Products & Tech Support
From: VASUKI M <vasukim1992002@gmail.com>
Date: Mon, 24 Feb 2025 at 16:20
Subject: Re: Bugs status tracking
To: Greg Sabino Mullane <htamfids@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, <alvherre@alvh.no-ip.org>
Cc: <pgsql-bugs@lists.postgresql.org>
Hi Greg,
Thanks for the suggestion. I have now resolved those issues. You can check my repository here: GitHub Issues.
I would appreciate it if Tom and Alvherre could review my repository. Once they approve, I will make it the main repository and work on pushing all the pgsql-bugs data there.
Best,
Vasuki
Looks pretty good. I would suggest getting the hyperlinks sorted out. If you look at this bug for example:--The message-id has an unwanted mailto link, and the first sentence has a mangled hyperlink.The word wrapping seems aggressive as well; it would be nice to keep the original formatting and allow things to be more than 80 characters (like this sentence, which is exactly 219 characters long and has no newlines).Searching by partial message id is hit or miss. "CACTY" matches nothing, but "CACTYHzjDSgV3qZu2stgBZ" does.That's a very well-written README.md (https://github.com/Vasuki-git/mailing-lists)Cheers,Greg--Crunchy Data - https://www.crunchydata.comEnterprise Postgres Software Products & Tech Support