[rfc] bug targeting in Launchpad

[Vincent Ladeuil]

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

    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.

    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.

    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.

    martin> Our releases are fairly strongly time-based but we do
    martin> care about fixing particular bugs for particular
    martin> releases, typically because they're serious
    martin> regressions or they're needed to deliver what's
    martin> supposed to be the headline feature for that release.

'headline feature' and 'time-based release' are the root of all
delays :-P

    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.

    martin> I think it's ok to have a bit of safety margin, by
    martin> marking things that _might_ be needed or we might
    martin> change our mind, but if we find we're regularly
    martin> having bugs not hit the release they're targeted to
    martin> our targeting is not honest.

Right, this has not been the case so far, to the best of my
knowledge.

    martin> "I'd like to do this for 1.x" is not a good use of
    martin> this marker.  If you want to do it soon, assign it to
    martin> yourself, and when you start mark it in progress.

Right, that may work better.

    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

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.

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.

        Vincent