[rfc] bug targeting in Launchpad

[Michael B. Trausch]

On Thu, 11 Jun 2009, Martin Pool wrote:

> This change from Vincent made me think about just what precisely it
> means when we target a bug to a release.
>
> We commonly target a bug after it's fixed as a record of which release
> included that fix.  That seems useful enough.
>
> What about targeting bugs that are not yet fixed?  The main effect of
> marking them is that they will come up in the milestone overview for
> that release, eg <https://edge.launchpad.net/bzr/+milestone/1.16>, and
> I think that page in turn is mostly useful for telling us:
>
> * what should I remember to work on soon
> * what needs attention but has nobody on it
> * are we ready to do the release?
>

This is what I use it for; my thought on it is that using the --fixes 
lp:###### and linking a commit to a launchpad bug is a good record for knowing 
when it was fixed, and targetting a bug to a release makes it easy to see what 
has left to be done to get that release situated.  At least, this is how I use 
it for AllTray.  If I don't know what release I want, I leave the milestone 
blank.  That way I can see what is what is still pending.  If something major 
comes up for the release I am planning that needs to be fixed right away, I 
will target it then for the release I am working on.  It helps me to see 
what's left to do without maintaining something else... for example:

   https://edge.launchpad.net/alltray/+milestone/0.7.3dev

Also, that way, if I have a bug that I haven't started work on yet, but is 
available for the picking that is high-enough priority that it needs to be 
done sooner rather than later, that is indicated by the linked milestone and 
someone could step in and work on it if they want.

> The first two are a bit redundant with bugs assigned to you and in
> progress, and with bugs of high or critical priority.  So I think
> targeting mostly comes down to the last one: what needs to be done to
> make the release, and does it need to slip?
>
> Our releases are fairly strongly time-based but we do care about
> fixing particular bugs for particular releases, typically because
> they're serious regressions or they're needed to deliver what's
> supposed to be the headline feature for that release.
>
> Therefore I think we should target bugs to releases only when it's
> something really critical to that release: we'd drop most other things
> to get this fixed, and we'd at least seriously consider slipping the
> release to put it in.  I think it's ok to have a bit of safety margin,
> by marking things that _might_ be needed or we might change our mind,
> but if we find we're regularly having bugs not hit the release they're
> targeted to our targeting is not honest.

Yeah, if it's up in the air, it's probably a good idea to not mark it and just 
leave it open-ended and get it fixed when it gets fixed.  Using --fixes on the 
bzr command line seems to work pretty well for me for keeping an idea when a 
bug is fixed.  I've thought about hooking the commit process on my system to 
ask me explicitly "Does this fix any bugs?" so I don't forget to use it, as I 
have a few times.  It would be nice if the "Related branches" section of a bug 
report on Launchpad were to indicate *which* commit fixed the bug to make it 
better to track, though...

> "I'd like to do this for 1.x" is not a good use of this marker.  If
> you want to do it soon, assign it to yourself, and when you start mark
> it in progress.
>
> Probably the other place where it makes sense to target is when it's a
> bug that's perhaps not critical, but it is almost done or in review or
> trivial, and we want to make sure that the small amount of remaining
> work does actually get done for this release.
>
> [I'm not sure which category vila's bug below fits into and I'm not
> saying he's wrong, just that it made me wonder why it was targeted.]
>
> What do you think?
>

Targeting bugs to be fixed in a release kind of helps to see the dependencies 
and ideas that are going into the development of something.  For example, if 
bzr had a longer release cycle, say, three or six months, and had point 
releases in-between as a matter of course, then filing a trivial bug or a 
regression that needs to be fixed within a release's maintenance cycle would 
be pretty easy; file the bug, have a triager mark it as targetted to the next 
point release.  It also provides some sense to users and other parties as to a 
time-line of when the bug is going to be fixed, even in projects like AllTray 
which aren't time-based releases where the only sense of time is a version 
number and loose plan behind that version number.

That's just my 2¢ though.

 	--- Mike