[dist-bugs] Use cases, etc

[Joey Hess]

With the buginfo microformat system I'm thining about, these usage
scenarios might look like this:

Lars Wirzenius wrote:
> Unlike most people on the list, I haven't really been thinking about
> distributed bug tracking very much yet. So I'd like to start at a bit
> higher level than implementation details like microformats or database
> design. I'd like to discuss use cases, personas, scenarios and so on.
> 
> Let me start by giving a couple of examples. First, a couple of
> imaginary users.
> 
>         * Amanda is a software developer, one of the main authors of a
>         wildly successful free software package

Amanda has chosen to use git, and picked one of the git-based, command
line bug trackers. She pushes her bug reports out with the rest of her
project's git repository, and they end up being "published" on its
gitweb.

Amanda has set up a buginfo aggregator on her project's website[2]. It
knows how to talk to her git-based bug tracker.

>         * Brenda is a college student majoring in theoretical physics.
>         As a hobby, she helps maintain Debian, and is one of the team
>         that maintains the Debian package of Amanda's software.

Brenda is using the Debian BTS, and she has a clone of Amanda's git
repo. The Debian BTS has buginfo support, and even includes a buginfo
aggregator.

>         * Cecil is a user of Amanda's software. He has no computer
>           expertese at all

Cecil visits a web forum when he needs help with Amanda's software.

Also, let's say that Dan is a Debian user, who uses reportbug at the
drop of a hat.

> Then, a couple of use cases or scenarios (not sure about the
> conventional terminology).
> 
>         * Report a new bug, either against the Debian package, or the
>         upstream package, and have the information be shared to the
>         other.
>         * Ask for additional information related to a bug.

Cecil reports a problem he has by posting to the forum. Amanda doesn't like
forums much, but she does check it occasionally. (Or she has a minion to
do it for her.)

When Amanda notices Cecil's forum post, she posts back, with a request
for some information[1].

Amanda also opens a bug report about the problem in her bug tracker in
git, and in that bug report, her bug report tool (emacs) automatically
includes a buginfo, with an url pointing at the aggregator on her
project's web site.

Dan, meanwhile, reports a bug using reportbug. Brenda gets the
report next time she runs offlineimap. 

Berenda pulls from Amanda's git repo, searches the upstream bug
list, and finds the bug Amanda recently filed, which looks like the same
problem. So she pastes its buginfo into a tool, that generates a reply
buginfo, which she then pastes into a reply mail sent to the Debian BTS.
In that reply she also asks Dan for a few more details.

Now, behind the scenes, some things happen, that basically causes
all the trackers to notice the other instances of the bug, and sync up.

  - Amanda's buginfo aggregator notices the buginfo she pushed out in her
    git repo, and creates a new page to track this new bug. The page gets
    a link to the forum post, and to the gitweb where Amanda's bug is
    published.

  - Debbugs sees that there's a buginfo in Brenda's mail to the BTS,
    and so it follows the link to Amanda's aggregator.

  - Amanda's aggregator notices the traffic, and updates the bug's page
    with a link back to the bug in the Debian BTS.

  - Amanda's aggregator can also talk to her git-based bug tracking
    system. So it drops a note in the bug report there, with a buginfo
    pointing to the bug in the Debian BTS.

  - Debbugs publishes a buginfo stating that it's maintaining a copy
    of this bug, and from Amanda's aggregator it pulls copies of all
    buginfos it's found about the bug so far. To the bug page in the
    Debian BTS, it adds links to the forum post, and to Amanda's gitweb.

  - Amanda's aggregator notices (via buginfo) that debbugs is not
    copying the bug, and records this, so that it can pass any more info
    along to debbugs.

All that happens in seconds or minutes. 

Now when Amanda updates her git repo, her bug tracker lets her know that
the bug has been reported in Debian, and gives her the link to the info
there.

>         * Add a comment to a bug, with more information to help the
>         developer find and fix the cause.

Cecil sees Amanda's request for more info, and she included her email
address ("I don't check this forum frequently"), so he emails her the
info.

Dan gets a mail from Brenda (via the Debian BTS, and note that this
mail includes a link to Amanda's buginfo tracker, so Dan could look up
Cecil's forum post if he wanted to.. but he doesn't).

Dan replies to Brenada's mail. Debbugs generates a buginfo for this
reply, and follows its link, alerting Amada's aggregator. (Aiee!)
Amanda's aggregator pushes a copy of Dan's reply into her git repo.

Amanda gets Cecil's mail, and files it in her git-based tracker, (and
again emacs includes a buginfo). When Amanda tries to git-push this
latest update it fails. Non-fast-forward.

So Amanda does a git-pull. Aha! Her git-based tracker alerts her
about Dan's reply. His workaround makes sense, and suggests a solution..

>         * Mark a bug as fixed, and include the fix or reference to it.

So Amanda codes up the fix, and in her commit message, emacs once again
inserts a buginfo. This one marks the bug as done.

Finally, the fix is pushed out. Amanda's aggregator sees at least two
new buginfos from that push, and updates, noting that the bug is fixed
in git, with a link to the commit in gitweb. It lets debbugs know about
these buginfos.

Debbugs sees that the bug has been fixed upstream, and tags it thus
in its own internal state. It generates a mail to Brenda to let her
know.

Brenda cherry-picks the fix from git, and puts a Closes: #nnnn in
debian/changelog, and uploads. 

Debbugs gets the resulting mail to nnnn-done, and marks the bug as 
closed. It generates a buginfo recording that fact, and follows it
to let Amanda's aggregator know.

-- 
see shy jo

[1] If Amanda includes a buginfo in this forum post, then Cecil
    can follow its link to her aggregator, and see the state of the bug.
    If not, he's probably left in the dark until Amanda announces a new
    version of the software.
[2] BTW, there's an alternate scenario where Amanda doesn't use a buginfo
    aggregator, or buginfos at all. Things still work, though Brenda has to
    do more of the work to get buginfos generated for things that Amanda
    records in her git-based tracker.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://kitenet.net/pipermail/dist-bugs/attachments/20080709/94ddd828/attachment-0001.pgp>