launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 19 September 2011 06:46, Robert Collins <robertc@xxxxxxxxxxxxxxxxx> wrote:
> On Thu, Sep 1, 2011 at 6:05 PM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
>> Distinguishing machine-set from user-set data seems like a really good
>> principle.  For me a totemic case is that 'fix released' really seems
>> very close to "targeted to a milestone which is now released", and
>> updating it from a script is not just a hassle (and makes mail noise)
>> but in a sense wrong.
>
> Thats a fascinating question right there. What counts as a milestone
> for the Launchpad web site?

It's hard to believe, but once upon a Launchpad did monthly numbered
releases, with targeted bugs, and then flipped them to released at
approximately the time that release was deployed.   But today, with
pretty frequent deployments, it stretches the concept of milestone
perhaps to the breaking point.

Like with status I think there are several concepts tied up inside 'milestone':

 * As a development manager, I want to make a list of bugs that all
need to be fixed together to complete a larger story (people also use
tags, and also wish for a generic bug-bag thing).
 * As a development team, we want to pre-commit to fixing a certain
set of bugs before we make a particular release.  (Personally I
question whether that is a good idea compared to using a priority
queue and time based releases, but it is a thing people want to do.)
 * As a development team, we want to document which bugs we actually
fixed in a completed release, so that we can look back in pleasure,
and tell people what changed.
 * As a user suffering a bug, I want to know which existing release is
supposed to have fixed it, so I can decide whether I need to upgrade,
or whether it's supposed to be fixed but actually not fixed or
regressed; or conversely I want to know when I am going to be able to
install a fix for it.

You could possibly split them all out entirely.

A few meta points:

The IssueTracker document and other discussions of this really imply a
fairly radical ("from the root") rethinking of the bug tracker
concept; on the other hand that seems risky given the amount of use it
gets today, and the relative lack of resources to do a really big
rework.  Perhaps it's possible to have a bold idea of simplification
but to take smaller steps.

Perhaps we can set some general rules about the desirable direction
and the way to make different changes and then they can be analyzed
step-by-step.  For instance I'd like to graft something like the
Answers.l.n "I answered the question" concept onto Incomplete bugs -
could that kind of stepwise improvement be accepted? (It probably
could.)

Generally I feel this has been talked about a lot over the years, and
it is more a matter of working out how to move it forward without
counting on getting a whole year for a massive rewrite.

I do feel like a lot of this is improved by a general pattern of
detangling separate things (like the analysis above, or splitting
crashes from bugs, or splitting "needs user input" from "confirmed",
or "confirmed" from "accepted").  There is some risk that this
analysis ends up with a perfectly-normalized but unwieldy model.  But,
that could probably be adequately mitigated through user testing etc,
especially if it's tackled one step at a time.

m