launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Aug 31, 2011 at 3:21 AM, Jonathan Lange <jml@xxxxxxxxx> wrote:
>> Perhaps we need to rethink how folk start their bugs and go from there...
>>
>> Something like:
>>
>> Users seek help: need something like 'answers'.
>> Some of these requests for assistance uncover symptoms of a problem in
>> the software (e.g. a crash, or user confusion from the UI). Call this
>> a problem statement.
>> A single *bug* could link or incorporate *many* problem statements.
>>
>
> What precisely do you mean by "bug" at this point?

I think I mean conceptual 'this is wrong' thing which when fixed all
the problem statements linked to it will be addressed (made no longer
reproducable I guess).

E.g. given 'libfoo-3 is broken, every package using it has to rebuild
against libfoo-4-dev' we would expect many problem statements, most
automatic from apport, and once a human looks at it we can identify
one root cause (broken library), but there are many actions needed to
fix it (rebuild successfully some N packages).

I think our 1 bug : N tasks model is a strength here, though having N
bugs with nice connections between them would let you address it too
(have one master bug 'libfoo-3 has rdepends' and N child bugs 'package
bar is linked to libfoo-3"). The main difference would be the number
of discussion threads - 1 bug:N tasks has one discussion, master bug
and child bugs has N discussions.

>> Fixing a bug might not address all the problem statements, so we'd
>> want to be able to work with that list pretty easily.
> ...
>
> I'm not quite sure what that means. Can you give a concrete example?

Taking my above example. Lets say that we have 300 automated problem
reports assessed in whatever way as being due to the same linking
problem. We rebuild everything and after that there are duplicate
problem statements coming in which match some of those 300 reports,
*but have the new library*. We'd want to split those out into a new
bug - we thought they were part of the same problem, but they were
not. Aggregating new things against this closed bug wouldn't be
helpful :).

>> This also suggests the documented workarounds angle could link to the
>> bug / task / problem statement - I'd be inclined to have them as FAQ's
>> linked to prior support requests in the support facet of this.
>>
>> tl;dr:
>>  - have users seek support.
>>  - migrate some support requests through to *symptom* or *problem* statements
>>  - aggregate those against bug tasks.
>>
>
> I think this is a sensible approach.
>
> Under this, are you thinking that we should preserve the "only one
> bugtask per bug target" model?

I hadn't really thought about that. bug->tasks gives us quite a bit of
strength but they are lacking anything to discriminate between tasks
other than the target. If we had a description for the task (e.g.
'rebuild' or 'update versions.cfg' or 'deploy it!') then that might
aid folk dealing with multi-task bugs even with the one task per
target limit - and makes a multi tasks per target model more obvious.

OTOH we could say bug dependencies are a better way to handle things
so complex they require multiple actions on a single target.

Or punt and offer both :)

There are some bits of system code that would need to change to allow
multiple tasks per target. The primary one that comes to mind is the
assumption when targeting that the presence of a task means no
additional task is desired; we'd probably want a rule something like:
1st rule in a target: 'whatever the current rules are'
Additional rules in a target: 'only folk that steer/drive/develop the
target can do this'

>> Anyhow, as I titled this, this is just me ruminating, but I'd sure
>> like us to find a core model that will address the friction we're
>> seeing today rather than tacking on more and more bits on the side :)
>>
>
> Obviously, it would be quite a big change. Very much agree with the last.
>
> Have you thought much about how this interacts with
> https://dev.launchpad.net/IssueTracker?

Not deeply. I don't think I can until that concept is a little more finished...

This "Therefore issue relationships should be recorded using free-form
text in the issue's description, with Launchpad automatically linking
issue numbers as it does now for bug numbers. " Seems an unjustified
conclusion.

There seems to be no space for a confirmed unapproved issue, nor for
an issue which has been triaged but is not ready to go. (Triaged as
something inferred by 'has a priority and is confirmed' would be fine,
but I can't tell if thats intended). Specifically, something that:
 - is real
 - but not very important to the project
how would the project get that off their radar without declining it or
doing -more- work to get it to ready?

Doing 'just enough' work on an item to get it out of the way defers
doing stuff up-front that may never be needed - thats the whole point
of triage (which point Ubuntu currently fails at because there is
nothing between Triaged and In Progress).

The section on work items seems incomplete - it says we will need them
to meet some spec, but not what means.

I'm adding these to the 'open issues' on the page now.

-Rob