On Wed, Aug 31, 2011 at 3:21 AM, Jonathan Lange <j...@mumak.net> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
