[dist-bugs] RFC: buginfo microformat (introduction & example)

[Joey Hess]

Hi everyone,

I have a long unfinished document that I'd appreciate your thoughts
about. I think I'll break it up in chunks as I become reasonably happy
with them. It'll be more digestable this way. Here goes..


## introduction

We all want [distributed bug tracking](http://dist-bugs.kitenet.net/), but
we don't really know yet how it should work. The closest software has
come to distributing it so far is piggybacking on a distributed VCS, which
has excellent potential for integration with software development. But
in a sense bug data in a VCS still lives in a data silo:

* Bugs can't be passed around from one project to another, unless both
  projects are really using the same underlying repository. Even in the case
  of a distribution and upstream, using a branch of the same repo for a
  package is still very much the exception, not the rule. And that's the easy
  case, what about the case of a distribution and its derivatives?
  What about a bug that affects every DNS server? (To pick one of today's
  headlines.)
* You have to use the VCS or tools around it (eg, ikiwiki) to file/edit
  a bug.

My core idea is that when you submit a bug, or add a comment to a bug in a
BTS, or commit a bug fix to revision control, or even blog about a bug, you
insert a little snippet of information, in a buginfo microformat, that
indicates what bug you're talking about, and what information you're adding
about it. And then these bits of data can be connected together and
aggregated by you, or others.

The buginfo microformat looks like this:

	[[buginfo url state={open,closed,...} ... id=type-data]]

Where the url is unique id for the bug, that aggregates together
information about the bug and its status from elsewhere on the net,
and the id is a unique id to use to refer to buginfos and tell them apart.

This is more a protocol for bug tracking than a bug tracking system.
This microformat can be used with existing bug tracking systems, and
it's hoped they would eventually gain native support for generating and
consuming it.

## example

If this document is considered a bug report of a sort, I could file a bug
on debbugs (or bugzilla, or whatever), asking it to support the
microformat, and include this in it:

	[[buginfo http://kitenet.net/~joey/blog/entry/bug_microformats
	state=open
	id=gpg-iD8DBQBIc7yG2tp5zXiKP0wRAvLZAJ95E1n5rec3bFNZ7wQt+1vQoOCtAwCgjEsbDhA0AnYg5LdDv3mpJ9F34O4==DQIt]]

Someone else might follow up on the bug in another medium. Perhaps they've
developed a patch. They include a buginfo too:

	[[buginfo http://kitenet.net/~joey/blog/entry/bug_microformats
	patch=http://example.com/~user/mypatch.diff
	ref=gpg-iD8DBQBIc7yG2tp5zXiKP0wRAvLZAJ95E1n5rec3bFNZ7wQt+1vQoOCtAwCgjEsbDhA0AnYg5LdDv3mpJ9F34O4==DQIt
	id=sha1-e83b60fc8c519ad38a2da23b90baba3014434f0b]]

Someone else might have a comment to make about that patch. They would include
a buginfo in their comment:

	[[buginfo http://kitenet.net/~joey/blog/entry/bug_microformats
	ref=sha1-e83b60fc8c519ad38a2da23b90baba3014434f0b
	id=sha1-8ab340c17c5739b9be3f2507ce729a8273b4c6ee]]

When I close the bug, I'd include a buginfo in the closure message:

	[[buginfo http://kitenet.net/~joey/blog/entry/bug_microformats
	state=closed ref=sha1-e83b60fc8c519ad38a2da23b90baba3014434f0b
	id=gpg-iD8DBQBIc8E32tp5zXiKP0wRAu1MAKDKl3PtfbU6TZ4QgPFtO3HNcdmUtACfRROMqh4YsdBghYrp8GmqE26F7k0==Ntll]]

As this is going on, the server at kitenet.net finds out in a couple of
ways about these buginfos that link to it:

* I (or a small shell script) could go to the bug report I filed, at
  http://bugs.debian.org/nnnnn, and click on the link back to the page;
  my site could then notice the HTTP referer.
* google, or similar search services, searching for pages linking to it
* It can be subscribed to a mailing list.
* A [trackback](http://en.wikipedia.org/wiki/Trackback) ping could 
  also be used. This would require that the BTS the buginfo is posted
  to be buginfo aware, so wouldn't be available at first, or all the
  time. For bootstrapping, referer is better.

In any case, my site would fetch each url it found, parse it to make sure it
contains a valid buginfo microformat, pull data out of the buginfo (is the
bug open or closed, etc), locally archive the url (in case it stopped being
available and I wanted to read it later), and update the page to link to it
and present a summary of the data.

-- 
see shy jo
-------------- 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/20080708/271cac28/attachment.pgp>