qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gitlab Issue Tracker - Proposed Workflow


From: John Snow
Subject: Re: Gitlab Issue Tracker - Proposed Workflow
Date: Wed, 5 May 2021 12:18:03 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 5/5/21 4:49 AM, Thomas Huth wrote:
On 04/05/2021 20.33, John Snow wrote:
[...]
- Gitlab will automatically close issues that reference the gitlab issue tracker from the commit message, but it won't apply the "Merged" label, so it's at risk of falling out of sync.

Closed issues retain their "Workflow::" labels, but won't show up in the issue search by default unless you ask to include closed issues as well.

I think we can likely just drop this label, and have bugs go directly from whatever state they're in to "Closed". The issue board will look cleaner and there's less custodial work for maintainers.

- Similarly to the above concern, "Released" is extra paperwork for us to maintain.
Others replied already, but I wanted to add some of my personal views here, too:

Since I suspect it will be you and I doing the janitoring, I think your opinion matters quite a bit :)

Hunting down the issues to close them after we published a new release was a very tedious and time consuming task. Most people simply forget to close tickets that they've opened or solved. So I was always doing most of the dirty work here, using a script to hunt down bug URLs in commit messages and looking for bugs that were stuck in "Fix committed" state - but honestly, I feel like I've also got better things to do in my spare time.

Agree.

So from my point of view: Let's close bugs automatically with the "Resolves:" keyword in the commit messages. I think users are smart enough to realize that the fix will then be available with the next release. So we really don't need a "Merged" and "Release" state anymore and I vote for dropping them.

Dropping Merged/Released seems noncontroversial, so I am doing that. Keeping it as simple as possible will be good for adoption. If we find we need more complexity, there's nothing stopping us from adding it later.

Thank you for your diligence on maintaining the Launchpad for so long! This migration would absolutely not be feasible without the care you've put into maintaining that tracker. (Or without your migration script! Thank you thank you!)

--js




reply via email to

[Prev in Thread] Current Thread [Next in Thread]