[dist-bugs] Use cases, etc

[Aidan Van Dyk]

All the below looks great in fantastic bright colours, but what about
the transient nature of the web and all it's URLs?    I don't expect the
debian URLs to change, but what about when Amanda gets married and
changes her name and thus domain, or dies and looses her domain, or just
decides to move on and passes ownership of her project on to someone
else, or just plain decides to switch SCM/BTS?

<disclaimer>my bias against the web and my lack of web2point0y knowledge
might be showing through here</disclaimer>

Throwing around URLs just seems like a recipe for loosing all the
precious data they reference.  Archiving that data into a meaningful and
collection is the whole point of a BTS...

* Joey Hess <joey at kitenet.net> [080709 15:41]:
 
> 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.

-- 
Aidan Van Dyk                                             Create like a god,
aidan at highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.
-------------- 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/260cb825/attachment.pgp>