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.