[rfc] bug targeting in Launchpad

[Martin Pool]

2009/6/12 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
>>>>>> "martin" == Martin Pool <mbp at sourcefrog.net> writes:
>
>    martin> This change from Vincent made me think about just
>    martin> what precisely it means when we target a bug to a
>    martin> release.
>
> Blush, thanks for pointing out, I haven't realized it may be
> misinterpreted.

It's no problem at all, it was a useful conversation.

>
>    martin> We commonly target a bug after it's fixed as a record
>    martin> of which release included that fix.
>
> Yes, when a bug is 'Fixed Released', it's good to know what
> releases include that fix.
>
> When it's 'Fix Commited', it's to good to know it should be
> available in the next release.
>
> I thought that for the other states things were less defined or
> undefined even.
>
> On the other hand, I don't remember having target releases
> available more than one release ahead either, so in fact I don't
> think we have been in a position to do that before.

I think there is documentation, but I'll check/update it.
>
>    martin> What about targeting bugs that are not yet fixed?
>    martin> The main effect of marking them is that they will
>    martin> come up in the milestone overview for that release,
>    martin> eg <https://edge.launchpad.net/bzr/+milestone/1.16>,
>    martin> and I think that page in turn is mostly useful for
>    martin> telling us:
>
>    martin>  * what should I remember to work on soon
>    martin>  * what needs attention but has nobody on it
>    martin>  * are we ready to do the release?
>
>    martin> The first two are a bit redundant with bugs assigned
>    martin> to you and in progress, and with bugs of high or
>    martin> critical priority.
>
> Bugs of high or critical priorities often lead to point
> releases. So I don't think this is redundant.

Ah, that's another factor I didn't mention.  If a bug is such that
we're going to include the fix in a point release updating something
that's previously come out then we should make a separate bugtask (ie
line in the status table) targeted at that *series*.

>    martin> So I think targeting mostly comes down to the last
>    martin> one: what needs to be done to make the release, and
>    martin> does it need to slip?
>
> Time-based releases don't slip.
>
> Err, wait, ok, that is really too critical to even do a release
> with it. It may be worth rolling back some patches and stick to
> the beat *EVEN* if it means knowing a point release will follow
> with the fix.
>
> I'm not proposing a new rule here, there is no rule to predict
> how many bugs a new feature will trigger, common sense and
> discussion should prevail, but if we had examples of feature
> rolled back for a release, we may be rush less to land fresh
> stuff.

Rushing features in or slipping a release to add them has usually
proved to be a bad idea.  Delaying a release to fix a bug is not great
but more justifiable, especially if it's a new regression in that
release.  It should still happen rarely.  Knowing what bugs need to be
done for a release ahead of time should be uncontroversial: we have
time to do them, we just need to remember that we will do them.  In
other words, they're things we _would_ slip for, but we're not _going
to_ slip for them.

>    martin> Therefore I think we should target bugs to releases
>    martin> only when it's something really critical to that
>    martin> release: we'd drop most other things to get this
>    martin> fixed, and we'd at least seriously consider slipping
>    martin> the release to put it in.
>
> That applies to critical bugs only I think.

Right, it's pretty much a tautology.  Though I modified this later on
to say I think it's also reasonable to target lower priority things
that are fix committed and we just want to make sure they land.

>    martin> Probably the other place where it makes sense to
>    martin> target is when it's a bug that's perhaps not
>    martin> critical, but it is almost done or in review or
>    martin> trivial, and we want to make sure that the small
>    martin> amount of remaining work does actually get done for
>    martin> this release.
>
> I was thinking about that when marking the bug below.
>
> More precisely, it went like:
>
> - what ? We still have *that* bug ?
> - shame I didn't know that the last time I hacked ftp,
> - not time to do it for 1.16,
> - workaround exist except for people forced to use ftp,
> - the bug is of medium priority,
> - not a lot of work,
> - not having in 2.0 will be unfortunate

I think a better way to do this would be: assign it to you, and then
we should be driving our list of assigned bugs to zero: either do it
if you care, or unassign it and admit you don't.

> Now, since your point seems mostly to be about using that target
> to decide if we can release or not, let me add this:

> For medium and low priority bugs, I find it totally legitimate to
> report them to the next release if they are not ready for
> inclusion in a time-base release.

I don't think I understand what you mean.

>
> That being said, I haven't thought about all the consequences
> when doing it, so I'll refrain from doing it again if we decide
> so.



-- 
Martin <http://launchpad.net/~mbp/>