Re: Gitlab Issue Tracker - Proposed Workflow

[Peter Maydell]

On Tue, 4 May 2021 at 19:34, John Snow <jsnow@redhat.com> wrote:
> # Some concerns on the above scheme:
>
> - "In Progress" is not likely to be used faithfully and will fall out of
> sync often. It's not clear if there should be a difference between a bug
> having an assignee and a bug labeled "In Progress". I don't want to get
> in the business of managing people's time and forcing them to track
> their work.
>
> At the same time, for bugs being actively fixed by a contributor on-list
> who is not [known to be] present on gitlab, it's still possibly a nice
> courtesy to mark a bug as not 'free for the taking'.
>
> Meanwhile, there are several bugs I "own" but I am not actually actively
> working on. These are the sorts of things that I wouldn't mind someone
> taking from me if they wanted to, so the "In Progress" label provides
> some useful distinction there if someone wished to use it.
>
> I think I am inclined to keep it for now, at least until gitlab adoption
> rate is higher and bugs can be assigned more faithfully.

I like "In Progress" because I use it largely to track "I wrote a
patch for this and submitted it to the list, but it hasn't gone in
yet". This means that later on when a release is more imminent I
can easily scan through a list of "in progress" bug reports to find
the "we just forgot to update the bug state when the patch was
committed" ones and the "somebody submitted a patch but it fell
through the cracks" ones. That's a lot harder if you have to look
through the whole pile of "new" bugs.

> - 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. I recommend instead we drop the label and begin using
> "Milestones" for each release, and attaching issues we have fixed or
> want to fix to specific Milestones. This will give us a way to track
> pending issues for release candidates as well as a convenient list, in
> the end, of which bugs were fixed in which specific release, which is
> far more useful than a "Released" tag anyway.

I guess so. I dunno how much our old fixed/released distinction
was helping users anyway. I do think that using Milestones both
for "I want to fix this bug for release X" and "this bug is fixed
in release X" is going to mean that it's not reliable for the latter
because we're going to have bugs where somebody optimistically set
the milestone and then the patches didn't land in time for the release.
But unless we care enough to write a bot that auto-updates milestones
we'll just have to live with that.

-- PMM