Gitlab Issue Tracker - Proposed Workflow

Gitlab Issue Tracker - Proposed Workflow

[John Snow]

I'm seeking feedback on our Gitlab issue handling workflow.
(There's a TLDR at the bottom of the mail.)


# Background:

Last KVM Forum, I started experimenting with the Gitlab issue tracker:
https://gitlab.com/qemu-project/qemu/-/issues

At the time, I hastily added some labels to roughly approximate our 
Launchpad issue lifecycle.

Gitlab offers "Scoped" labels that allow us to set a 'category' of 
labels where only one label from that category at a time may be applied.

I created the "Workflow::" scope to create labels for our issue 
lifecycle. You can see how this looks like by visiting our issue board:
https://gitlab.com/qemu-project/qemu/-/boards

Workflow labels can be changed by manually setting or removing tags, OR 
by clicking and dragging issues from one column of the board to another.


# The Workflow:: states we have currently:

https://gitlab.com/qemu-project/qemu/-/labels?utf8=%E2%9C%93&subscribed=&search=workflow

- [Open] - For newly created issues. These show up in the far-left panel 
on the boards view and allow us to quickly see which bugs have not been 
assigned a Workflow:: label. The intent is to keep this list as empty as 
possible, aggressively moving things into "Needs Info" or "Triaged" lists.

- Needs Info: For issues that either cannot be triaged or cannot be 
verified because they lack information. The intent is to allow the CI 
Janitor to close such issues after 60 days of inactivity.

- Triaged: For issues that have been classified (Bug/Feature), and 
sorted into their appropriate topic label(s) -- e.g. Storage, Audio, 
accel: TCG, etc. The intent is that subsystem maintainers will subscribe 
to relevant topics and either re-triage, kick it back to Needs Info, 
assign someone, etc.

- In Progress: For issues that a developer is actively working on. The 
intent was to be able to mark bugs in such a way that contributors would 
not assume they are available to be hacked on. For instance, if a 
non-gitlab contributor submits patches for an issue, we might mark it as 
In Progress so that it does not appear to be going unaddressed.

- Merged: Intended for issues that have had code that is merged, but not 
yet released. This was done to mimic our Launchpad workflow.

- Released: Intended for issues that have had been fixed and packaged in 
a release. This was also added to mimic Launchpad.

- [Closed] - For issues that are resolved in one way or another.


# 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.


- 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.


- "Triaged" is a very lightweight label that I created only to mean that 
the bug has been seen and tagged, which will hopefully deliver it to 
someone's queue that they are paying attention to. It does not 
necessarily mean "Tested and Confirmed". It's possible we may want a new 
label "Confirmed" to help us sort through reports in a way that's a 
little more meaningful than just "triaged".


# TLDR:

- Let's keep "Workflow::In Progress", but acknowledge it as informative
   instead of exhaustive.
- Let's drop "Workflow::Merged" and just rely on the auto-close feature.
- Let's drop "Workflow::Released" and use the Milestones feature to help
   us with our changelog auditing.
- Let's add "Workflow::Confirmed" to help distinguish lightly-triaged
   bugs from serious, actionable bugs.


If I don't hear back, I'll assume everyone agrees and start making the 
changes.
(Though, to manage milestones, I'll need the 'Developer' role.)

Thanks,
--js

Re: Gitlab Issue Tracker - Proposed Workflow

[Daniel P. Berrangé]

On Tue, May 04, 2021 at 02:33:58PM -0400, John Snow wrote:
> I'm seeking feedback on our Gitlab issue handling workflow.
> (There's a TLDR at the bottom of the mail.)
> 
> 
> # Background:
> 
> Last KVM Forum, I started experimenting with the Gitlab issue tracker:
> https://gitlab.com/qemu-project/qemu/-/issues
> 
> At the time, I hastily added some labels to roughly approximate our
> Launchpad issue lifecycle.
> 
> Gitlab offers "Scoped" labels that allow us to set a 'category' of labels
> where only one label from that category at a time may be applied.
> 
> I created the "Workflow::" scope to create labels for our issue lifecycle.
> You can see how this looks like by visiting our issue board:
> https://gitlab.com/qemu-project/qemu/-/boards
> 
> Workflow labels can be changed by manually setting or removing tags, OR by
> clicking and dragging issues from one column of the board to another.
> 
> 
> # The Workflow:: states we have currently:
> 
> https://gitlab.com/qemu-project/qemu/-/labels?utf8=%E2%9C%93&subscribed=&search=workflow
> 
> - [Open] - For newly created issues. These show up in the far-left panel on
> the boards view and allow us to quickly see which bugs have not been
> assigned a Workflow:: label. The intent is to keep this list as empty as
> possible, aggressively moving things into "Needs Info" or "Triaged" lists.
> 
> - Needs Info: For issues that either cannot be triaged or cannot be verified
> because they lack information. The intent is to allow the CI Janitor to
> close such issues after 60 days of inactivity.
> 
> - Triaged: For issues that have been classified (Bug/Feature), and sorted
> into their appropriate topic label(s) -- e.g. Storage, Audio, accel: TCG,
> etc. The intent is that subsystem maintainers will subscribe to relevant
> topics and either re-triage, kick it back to Needs Info, assign someone,
> etc.
> 
> - In Progress: For issues that a developer is actively working on. The
> intent was to be able to mark bugs in such a way that contributors would not
> assume they are available to be hacked on. For instance, if a non-gitlab
> contributor submits patches for an issue, we might mark it as In Progress so
> that it does not appear to be going unaddressed.

If someone is actively working on it, they could just stick a comment
on the issue, possibly with a mailing list posting.

With a simple "in progress" flag you can end up marking things as if
someone is working on it, but then they go off and do other things.

If you just have a mailing list posting/comment, you can at least
see how up2date that comment was and judge whether the person is
still caring about the bug.

> 
> - Merged: Intended for issues that have had code that is merged, but not yet
> released. This was done to mimic our Launchpad workflow.
> 
> - Released: Intended for issues that have had been fixed and packaged in a
> release. This was also added to mimic Launchpad.
> 
> - [Closed] - For issues that are resolved in one way or another.
> 
> 
> # 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.
> 
> 
> - 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.

Yeah, if we really wnat to record release info against bugs, then the
milestones looks more useful, but....

Generating a list of bugs in the release is only useful if that list
is reasonably complete. That means we need someone who really cares
about this because most people will never bother to set a milestone
and so some janitor will have to cleanup for each release. I'm loathe
to define a system that creates busy-work for someone unless they
definitely want that work.

IOW, in abence of a janitor volunteering, I'd just keep life simple
and let bugs be marked closed as they get merged via the commit message.

We can query bugs linked to commits in this way, and I feel we'll have
more luck getting maintainers to reliably add bug links in commits
than playing with milestones.

> - "Triaged" is a very lightweight label that I created only to mean that the
> bug has been seen and tagged, which will hopefully deliver it to someone's
> queue that they are paying attention to. It does not necessarily mean
> "Tested and Confirmed". It's possible we may want a new label "Confirmed" to
> help us sort through reports in a way that's a little more meaningful than
> just "triaged".
> 
> 
> # TLDR:
> 
> - Let's keep "Workflow::In Progress", but acknowledge it as informative
>   instead of exhaustive.

Personally I'd drop this one too

> - Let's drop "Workflow::Merged" and just rely on the auto-close feature.
> - Let's drop "Workflow::Released" and use the Milestones feature to help
>   us with our changelog auditing.


> - Let's add "Workflow::Confirmed" to help distinguish lightly-triaged
>   bugs from serious, actionable bugs.

I wonder if instead of that we could just have some prioritization
tags eg 

  - "Regression" - something that previously worked and we broke

  - "Release blocker" - we decided we must have this fixed in the
    next relaase - currently we paste such bugs into the planning
    page wiki for a release

  - "Important" - something that's high priority to address


This confer more useful meaning that a "Confirmed" tag I think.

Anything else without those tags can be considered a "normal" bug
that may or may not be dealt.


So I wonder if it just suffices to have standalone "workflow:triaged" and
"workflow:needinfo" flags, possibly as prefixed labels, not scoped labels.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

Re: Gitlab Issue Tracker - Proposed Workflow

[John Snow]

On 5/4/21 2:52 PM, Daniel P. Berrangé wrote:
> On Tue, May 04, 2021 at 02:33:58PM -0400, John Snow wrote:
>> I'm seeking feedback on our Gitlab issue handling workflow.
>> (There's a TLDR at the bottom of the mail.)

>> - In Progress: For issues that a developer is actively working on. The
>> intent was to be able to mark bugs in such a way that contributors would not
>> assume they are available to be hacked on. For instance, if a non-gitlab
>> contributor submits patches for an issue, we might mark it as In Progress so
>> that it does not appear to be going unaddressed.
> 
> If someone is actively working on it, they could just stick a comment
> on the issue, possibly with a mailing list posting.
> 
> With a simple "in progress" flag you can end up marking things as if
> someone is working on it, but then they go off and do other things.
> 
> If you just have a mailing list posting/comment, you can at least
> see how up2date that comment was and judge whether the person is
> still caring about the bug.
> 

I can see this critique. OTOH, and as Peter has written, it's also a 
fine way to find a list of candidate bugs that we may have forgotten about.

Ideally people still post a link to the patch if they move it to "in 
progress" so we get the benefits of both methods. I usually try to link 
to a mailing list thread whenever I update a BZ/LP like this. I can keep 
that habit alive here.

It might be fine as simply an informational state that we just don't 
treat as authoritative/exhaustive.

>> - 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.
> 
> Yeah, if we really wnat to record release info against bugs, then the
> milestones looks more useful, but....
> 
> Generating a list of bugs in the release is only useful if that list
> is reasonably complete. That means we need someone who really cares
> about this because most people will never bother to set a milestone
> and so some janitor will have to cleanup for each release. I'm loathe
> to define a system that creates busy-work for someone unless they
> definitely want that work.
> 
> IOW, in abence of a janitor volunteering, I'd just keep life simple
> and let bugs be marked closed as they get merged via the commit message.
> 
> We can query bugs linked to commits in this way, and I feel we'll have
> more luck getting maintainers to reliably add bug links in commits
> than playing with milestones.
> 

Yeah, I don't expect us to do all of our release planning in Gitlab. 
This is merely a convenient way to associate an issue with a release.

I'm personally willing to do SOME of the janitoring here; in that I can 
associate closed issues with a release milestone and -- when preparing 
for rc0 freeze -- punt off any bugs that aren't blockers/in-progress to 
the next milestone.

I don't expect it would become an *exhaustive* list of changes, just 
merely a way to associate the things that DID make it into the issue 
tracker with a release.

It may allow us to publish a nice list in the changelog with links to 
the gitlab issue tracker each release, which might be nice because issue 
tracker bugs are often ones that end-users filed, so it's a way to pay 
very visible attention to that feedback.

>> - Let's add "Workflow::Confirmed" to help distinguish lightly-triaged
>>    bugs from serious, actionable bugs.
> 
> I wonder if instead of that we could just have some prioritization
> tags eg
> 
>    - "Regression" - something that previously worked and we broke
> 
>    - "Release blocker" - we decided we must have this fixed in the
>      next relaase - currently we paste such bugs into the planning
>      page wiki for a release
> 
>    - "Important" - something that's high priority to address
> 
> 
> This confer more useful meaning that a "Confirmed" tag I think.
> 

Definitely nothing stopping us from adding those labels outside of the 
Workflow scope.

"Regression" might be nice for highlighting issues for inclusion into 
the next stable release.

"Release blocker" could be just as well served by inclusion in the 
upcoming Milestone. (Granted: there would be no difference between stuff 
that's puntable or not-puntable, so there may indeed be some use to a 
"Blocker" label.)

"Important" might be best served by the "weight" fields, and might be a 
bit too subjective.

> Anything else without those tags can be considered a "normal" bug
> that may or may not be dealt.
> 
> 
> So I wonder if it just suffices to have standalone "workflow:triaged" and
> "workflow:needinfo" flags, possibly as prefixed labels, not scoped labels.
> 

I think I am rather fond of having the scoped labels for the sake of 
making the "Board" view interesting to look at.

Open --> Triaged --> Confirmed --> In Progress --> Closed

In this view, each column suggests work that can be done to help move it 
along the pipeline. Tagging open bugs will be an important step in 
making this issue tracker useful to everyone.

We *could* move everything to individual labels, but I find a benefit to 
scoped labels is that you can't mis-use them by applying more than one, 
so there's less janitoring to do.

I also like that scoped labels suggest the full lifecycle of the issue, 
so you don't have to dig through the full list of labels.

(Also: if you don't know about ANY of the Workflow labels, the board 
view provides a canonical overview, so it's a fairly discoverable process.)

> Regards,
> Daniel
> 

Thanks for the feedback today, on IRC and now on-list. :~)

--js

Re: Gitlab Issue Tracker - Proposed Workflow

[John Snow]

On 5/4/21 4:24 PM, Peter Maydell wrote:
> 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.
> 

Yeah, I think that's something that winds up being nice. As an 
informational/non-exhaustive label, you can at least quickly search them 
to see if you can close any of those bugs if we missed 'em.

Good argument for keeping that state for now.

>> - 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.
> 

Not a huge problem to punt "I want to fix" issues off to the next 
release during the rc0 phase. Writing a script to do this should be 
pretty easy:

Just look for any issues in Milestone 6.1.0 that are still Open and not 
marked 'Blocker/Regression/In Progress' (as examples) and either punt 
them to 6.2.0 or simply delete their milestone association and allow 
someone who cares to re-assess.

> -- PMM
> 

Thanks!

--js

Re: Gitlab Issue Tracker - Proposed Workflow

[Thomas Huth]

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: 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.
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.

  Thomas

Re: Gitlab Issue Tracker - Proposed Workflow

[John Snow]

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