Merged Trevor's tree

32 files changed, 986 insertions, 0 deletions

diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body
new file mode 100644
index 0000000..d3f00e7
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body
@@ -0,0 +1,25 @@
+Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+
+> the basic idea is to take a look at all public branches (for exaple
+> all on lp/bitbucket/github) in order to tell the user of a
+> webinterface that bug foo is fixed in branch xyz, and if its merged to
+> the main branch
+
+I don't understand. The state of the bug in the main branch is right
+there in the main branch; if it's not fixed there, it's not fixed there.
+If it's merged in from a different branch, the bug state follows all the
+other changes when they come in.
+
+Can you give an example of what would be done differently?
+
+-- 
+ \           “The basic fact about human existence is not that it is a |
+  `\                tragedy, but that it is a bore.” —Henry L. Mencken |
+_o__)                                                                  |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values
new file mode 100644
index 0000000..4c93931
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values
@@ -0,0 +1,14 @@
+Alt-id: <874otjmjhr.fsf@benfinney.id.au>
+
+
+Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 23:34:08 +1000
+
+
+In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body
new file mode 100644
index 0000000..1f6d84b
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body
@@ -0,0 +1,28 @@
+On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> 1. is there any way to aggregate over multiple public branches in order
+> to get the complete bug state
+
+Keeping the bug data with the source helps synchronize bug state and
+source code.  Bug state in branch A may not apply to branch B.  Some
+people like to weaken this source-bug linkage by keeping their bugs in
+a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+currently supports this workflow).  It sounds like you want to move
+from "bugs with code" to "bugs and code in separate branches".  We
+don't have an easy way to do that in BE at the moment, since
+version-control systems like Git have a single working branch at a
+time (I think :p).  What VCS are you using as a backend?
+
+> 2. is there any model for storing bigger files at a central place (for
+> some of my bugs i have multi-megabyte tarballs attached)
+
+  be comment ID "See the tarball at http://yourpage/something.tar.gz"
+Then to grab the tarball, you'd use:
+  wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+to grab it.
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values
new file mode 100644
index 0000000..a73aeeb
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values
@@ -0,0 +1,14 @@
+Alt-id: <20090711125030.GA18185@mjolnir.home.net>
+
+
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 08:50:30 -0400
+
+
+In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body
new file mode 100644
index 0000000..bd9e63a
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body
@@ -0,0 +1,25 @@
+Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+
+> 1. is there any way to aggregate over multiple public branches in
+> order to get the complete bug state
+
+The bug state is as complete as the source code state. It's exactly as
+aggregated as the rest of the source code; the “complete bug state”
+would be the integration branch where you merge all the feature branches
+and bug-fix branches together.
+
+If instead you want bugs to *not* be tightly linked with the rest of the
+source code state, it seems you don't want a distributed bug tracker
+like Bugs Everywhere.
+
+-- 
+ \     “I cannot conceive that anybody will require multiplications at |
+  `\   the rate of 40,000 or even 4,000 per hour …” —F. H. Wales, 1936 |
+_o__)                                                                  |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values
new file mode 100644
index 0000000..55621fb
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values
@@ -0,0 +1,14 @@
+Alt-id: <878wivmjm1.fsf@benfinney.id.au>
+
+
+Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 23:31:34 +1000
+
+
+In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body
new file mode 100644
index 0000000..11f344c
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body
@@ -0,0 +1,93 @@
+On Mon, Jul 13, 2009 at 09:05:34AM +0200, Ronny Pfannschmidt wrote:
+> On Sun, 2009-07-12 at 19:55 -0400, W. Trevor King wrote:
+> > On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote:
+> > > On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> > > > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > > > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > > > > 2. is there any model for storing bigger files at a central place (for
+> > > > > > > some of my bugs i have multi-megabyte tarballs attached)
+> > > > > > 
+> > > > > >   be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > > > > Then to grab the tarball, you'd use:
+> > > > > >   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > > > > to grab it.
+> > > > >
+> > > > > so the basic idea is to do it completely self-managed
+> > > > > and have have heterogenous sources of extended data?
+> > > > 
+> > > > I assume "extended data" here refers to your tarballs.  What sort of
+> > > > homogenous source did you have in mind?  The comment body is currently
+> > > > just a binary blob for non-text/* types, otherwise it's text in
+> > > > whatever encoding you've configured.
+> > >
+> > > some kind of common upload target for a single project in order to have
+> > > more reliable sources of stuff thats related to bugs but doesnt fit into
+> > > the normal repository
+> > 
+> > Sorry, I'm still having trouble with "doesn't fit into the normal
+> > repository".  It's going to be large wherever you keep it.  You
+> > worried about multiple branches all having these big tarballs in them
+> > and want a "lightweight" checkout without all the big
+> > tarballs/whatever?  I still think having some sort of "resources"
+> > directory on an http server somewhere that you link to from comments
+> > is the best plan.  If you use the
+> >   be show --xml ID | be-xml-to-mbox | catmutt
+> > approach, you can even write your comments in text/html and get
+> > clickable links ;).  A "push big file to remote and commit comment
+> > linking to it" script would be pretty simple and keep everything
+> > consistent.
+>
+> thats probably what i want to do
+
+#!/bin/bash
+REMOTE_DIR="you@webhost:./public_html/bigfiles"
+REMOTE_LINK="http://www.webhost.com/bigfiles"
+if [ $# -ne 2 ]; then
+   echo "usage: $0 ID BIGFILE"
+   exit 1
+fi
+ID="$1"
+BIGFILE="$2"
+be comment "$ID" "Large file stored at ${REMOTE_LINK}/${BIGFILE}" && scp "$BIGFILE" "${REMOTE_DIR}"
+
+> > > > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > > > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> > > > > 
+> > > > > > i want to see the combination of the bug data of all branches
+> > > > > 
+> > > > > How is a tool to determine the set of “all branches”? The distributed
+> > > > > VCS model means that set is indeterminate.
+> > > > 
+> > > > He could just make a list of branches he likes.
+> > > > 
+> > > > Ronny, are you looking to check bug status across several repos on the
+> > > > fly, or periodically run something (with cron, etc.) to update a
+> > > > static multi-repo summary?
+> > >
+> > > on the fly access
+> > 
+> > Then listing bugs in a remote repo will either involve httping tons of
+> > tiny values files for each bug (slow?) or running some hypothetical
+> > BE-server locally for each repo speaking some BE-specific protocol
+> > (complicated?).  And how would you handle e.g. headless git repos,
+> > where nothing's even checked out?
+> > 
+> > You could always run the cron job every 15 minutes, and rely on
+> > whatever VCS you're using having some intelligent protocol/procedure
+> > to keep bandwidth down ;).  If you need faster / more-efficient
+> > updates, you'll probably need to throw out polling altogether and
+> > setup all involved repos with a "push to central-repo on commit" hook
+> > or some such.
+>
+> its intended to run on the place where i publish the repositories anyway
+
+Oh, you mean all the repos you want to cover are all _already_ on the
+same host?
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values
new file mode 100644
index 0000000..bb2305f
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values
@@ -0,0 +1,14 @@
+Alt-id: <20090713104715.GA13723@mjolnir.home.net>
+
+
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 06:47:15 -0400
+
+
+In-reply-to: 6dcc910a-ce15-4eeb-b49b-4747719748ed
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body
new file mode 100644
index 0000000..cf3c990
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body
@@ -0,0 +1,32 @@
+On Sat, Jul 11, 2009 at 11:25:07AM -0400, W. Trevor King wrote:
+> The easiest implementation I can think of would be to keep local
+> branches (on whatever computer is hosting your web interface)
+> following your favorite repos.
+>   proxectX/
+>   |-- repoA
+>   |-- repoB
+>   `-- repoC
+> You'd pull upstream changes with a cron job.
+> Listing bugs would be something along the lines of
+>   projectX$ for repo in *
+>             do
+>               pushd $repo
+>               be list
+>               popd
+>             done | sort | uniq
+> ...
+
+I've reworked option handling for be, so my branch now supports
+  projectX$ for repo in *
+            do
+              be --dir $repo list
+            done | sort | uniq
+etc.  This also makes it easy to use your uninstalled development
+version of be on any bug directory on your local machine.
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values
new file mode 100644
index 0000000..60c80a1
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values
@@ -0,0 +1,14 @@
+Alt-id: <20090713115734.GA13788@mjolnir.home.net>
+
+
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 07:57:34 -0400
+
+
+In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body
new file mode 100644
index 0000000..c22de06
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body
@@ -0,0 +1,73 @@
+On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote:
+> On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > > 2. is there any model for storing bigger files at a central place (for
+> > > > > some of my bugs i have multi-megabyte tarballs attached)
+> > > > 
+> > > >   be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > > Then to grab the tarball, you'd use:
+> > > >   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > > to grab it.
+> > >
+> > > so the basic idea is to do it completely self-managed
+> > > and have have heterogenous sources of extended data?
+> > 
+> > I assume "extended data" here refers to your tarballs.  What sort of
+> > homogenous source did you have in mind?  The comment body is currently
+> > just a binary blob for non-text/* types, otherwise it's text in
+> > whatever encoding you've configured.
+>
+> some kind of common upload target for a single project in order to have
+> more reliable sources of stuff thats related to bugs but doesnt fit into
+> the normal repository
+
+Sorry, I'm still having trouble with "doesn't fit into the normal
+repository".  It's going to be large wherever you keep it.  You
+worried about multiple branches all having these big tarballs in them
+and want a "lightweight" checkout without all the big
+tarballs/whatever?  I still think having some sort of "resources"
+directory on an http server somewhere that you link to from comments
+is the best plan.  If you use the
+  be show --xml ID | be-xml-to-mbox | catmutt
+approach, you can even write your comments in text/html and get
+clickable links ;).  A "push big file to remote and commit comment
+linking to it" script would be pretty simple and keep everything
+consistent.
+
+> > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> > > 
+> > > > i want to see the combination of the bug data of all branches
+> > > 
+> > > How is a tool to determine the set of “all branches”? The distributed
+> > > VCS model means that set is indeterminate.
+> > 
+> > He could just make a list of branches he likes.
+> > 
+> > Ronny, are you looking to check bug status across several repos on the
+> > fly, or periodically run something (with cron, etc.) to update a
+> > static multi-repo summary?
+>
+> on the fly access
+
+Then listing bugs in a remote repo will either involve httping tons of
+tiny values files for each bug (slow?) or running some hypothetical
+BE-server locally for each repo speaking some BE-specific protocol
+(complicated?).  And how would you handle e.g. headless git repos,
+where nothing's even checked out?
+
+You could always run the cron job every 15 minutes, and rely on
+whatever VCS you're using having some intelligent protocol/procedure
+to keep bandwidth down ;).  If you need faster / more-efficient
+updates, you'll probably need to throw out polling altogether and
+setup all involved repos with a "push to central-repo on commit" hook
+or some such.
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values
new file mode 100644
index 0000000..b5ebf31
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values
@@ -0,0 +1,14 @@
+Alt-id: <20090712235502.GA10782@mjolnir.home.net>
+
+
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 12 Jul 2009 19:55:02 -0400
+
+
+In-reply-to: 8ffc90d7-0be7-4b00-88e6-9ae1b65f7957
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body
new file mode 100644
index 0000000..e7b48e0
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body
@@ -0,0 +1,83 @@
+I read
+  http://weblog.masukomi.org/2008/1/3/distributed-bug-tracking
+yesterday, and the section on bug visibility got me thinking about
+bug 12c (Multi-repo meta-BE?) some more.
+
+We already have interfaces like this email/html mashup:
+
+On Sun, Sep 13, 2009 at 07:04:05AM -0400, W. Trevor King wrote:
+> Since the non-bzr interfaces to BE are coming along nicely, I've put
+> up a non-bzr interface to my be-rr branch.
+>   http://www.physics.drexel.edu/~wking/code/be
+> It uses nightly builds of Gianluca's static html from my devel branch
+> to provide read-only browsing, and accepts changes from the general
+> public through my email interface into a public branch.  I handle the
+> synchronization of these two branches manually.
+
+These interfaces provide a means for remote users to access a BE
+repository without bzr or the command line.  As far as users are
+concerned, this exposed repository looks pretty much like a
+centralized bugtracking system (e.g. bugzilla, ...).
+
+However, with BE we have more bug information living off in other
+branches that haven't yet been merged with the exposed repo.  The
+problem is two-fold:
+  1) how to keep up to date within a distributed community.
+  2) how do users find branches/patches that fix bug XYZ.
+
+For (2), I think the best solution at the moment are along the lines
+of my little scripts (discussed in the bug 12c comments).  With the
+addition of the `be diff --dir DIR` option, it's now even easier to
+find more information on bug 565 (or whatever UUID):
+  be/be.wtk$ for repo in ../*; do \
+              if [ $repo == "be.wtk" ]; then continue; fi; \
+              diff=$(be diff --dir $repo --subscribe 565:all); \
+              if [ -n "$diff" ]; then \
+                echo "Changed from $repo:"; echo "$diff"; \
+              fi; \
+             done
+  Changed from ../be.html:
+  New bugs:
+    565:fm: be email-bugs for bug submission from bzr-less users
+  Changed from ../be.trunk:
+  New bugs:
+    565:fm: be email-bugs for bug submission from bzr-less users
+  Changed from ../cherryflavoredbugseverywhere:
+  New bugs:
+    565:fm: be email-bugs for bug submission from bzr-less users
+where the --dir and --subscribe options to `be diff` are new.  If
+people don't like the command line, this would be easy to bundle into
+a web-frontend (CFBE?) if you wanted, with a cron job pulling updates
+into the tracked branches.
+
+I was starting into a solution for (1) when I did this:
+
+On Mon, Jul 27, 2009 at 08:42:19AM -0400, W. Trevor King wrote:
+> My email interface now supports subscription:
+>   be subscribe DIR       # see any changes to the bug directory.
+>   be subscribe BUG-ID    # see changes to a particular bug.
+> See
+>   be subscribe --help
+> for more details.
+
+The idea was that a dev/user would subscribe to whatever issues they
+wanted to track, and they would get email notifications whenever some
+action affected any of those issues.  These subscriptions would
+percolate through the distributed branches as a result of the usual
+mergers.  For example, my subscription to all changes has made it into
+the trunk branch (see .be/settings).
+
+This subscription mechanism was setup to work through interactive
+public interfaces (my email interface, eventually CFBE, ...), but
+it doesn't work for changes made via the command-line interface,
+so I browsed around a bit and ran across some interesting workflows
+in the bzr documentation
+  doc/developers/HACKING.txt, "Communicating and Coordinating"
+which points out the following plugins
+  * email (http://doc.bazaar-vcs.org/plugins/en/email-plugin.html)
+  * dbus (http://doc.bazaar-vcs.org/plugins/en/dbus-plugin.html)
+which send automatic notification messages after commits, etc.  If
+people want this sort of functionality, it would be easy enough to rig
+a hook for `be commit' that sent a diff email to subscribers, which
+could include be-devel.
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values
new file mode 100644
index 0000000..adb1ae5
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values
@@ -0,0 +1,8 @@
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 05 Dec 2009 22:39:07 +0000
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body
new file mode 100644
index 0000000..6b7d3eb
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body
@@ -0,0 +1,70 @@
+On Sun, 2009-07-12 at 19:55 -0400, W. Trevor King wrote:
+> On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote:
+> > On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> > > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > > > 2. is there any model for storing bigger files at a central place (for
+> > > > > > some of my bugs i have multi-megabyte tarballs attached)
+> > > > > 
+> > > > >   be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > > > Then to grab the tarball, you'd use:
+> > > > >   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > > > to grab it.
+> > > >
+> > > > so the basic idea is to do it completely self-managed
+> > > > and have have heterogenous sources of extended data?
+> > > 
+> > > I assume "extended data" here refers to your tarballs.  What sort of
+> > > homogenous source did you have in mind?  The comment body is currently
+> > > just a binary blob for non-text/* types, otherwise it's text in
+> > > whatever encoding you've configured.
+> >
+> > some kind of common upload target for a single project in order to have
+> > more reliable sources of stuff thats related to bugs but doesnt fit into
+> > the normal repository
+> 
+> Sorry, I'm still having trouble with "doesn't fit into the normal
+> repository".  It's going to be large wherever you keep it.  You
+> worried about multiple branches all having these big tarballs in them
+> and want a "lightweight" checkout without all the big
+> tarballs/whatever?  I still think having some sort of "resources"
+> directory on an http server somewhere that you link to from comments
+> is the best plan.  If you use the
+>   be show --xml ID | be-xml-to-mbox | catmutt
+> approach, you can even write your comments in text/html and get
+> clickable links ;).  A "push big file to remote and commit comment
+> linking to it" script would be pretty simple and keep everything
+> consistent.
+thats probably what i want to do
+
+> 
+> > > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> > > > 
+> > > > > i want to see the combination of the bug data of all branches
+> > > > 
+> > > > How is a tool to determine the set of “all branches”? The distributed
+> > > > VCS model means that set is indeterminate.
+> > > 
+> > > He could just make a list of branches he likes.
+> > > 
+> > > Ronny, are you looking to check bug status across several repos on the
+> > > fly, or periodically run something (with cron, etc.) to update a
+> > > static multi-repo summary?
+> >
+> > on the fly access
+> 
+> Then listing bugs in a remote repo will either involve httping tons of
+> tiny values files for each bug (slow?) or running some hypothetical
+> BE-server locally for each repo speaking some BE-specific protocol
+> (complicated?).  And how would you handle e.g. headless git repos,
+> where nothing's even checked out?
+> 
+> You could always run the cron job every 15 minutes, and rely on
+> whatever VCS you're using having some intelligent protocol/procedure
+> to keep bandwidth down ;).  If you need faster / more-efficient
+> updates, you'll probably need to throw out polling altogether and
+> setup all involved repos with a "push to central-repo on commit" hook
+> or some such.
+its intended to run on the place where i publish the repositories anyway
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values
new file mode 100644
index 0000000..bbeacb6
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values
@@ -0,0 +1,14 @@
+Alt-id: <1247468734.7189.1.camel@localhost>
+
+
+Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 09:05:34 +0200
+
+
+In-reply-to: 4d192c6c-a4a8-4844-b083-2dd5926bd2d9
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body
new file mode 100644
index 0000000..2f2c16e
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body
@@ -0,0 +1,15 @@
+Hi,
+
+1. is there any way to aggregate over multiple public branches in order
+to get the complete bug state
+
+2. is there any model for storing bigger files at a central place (for
+some of my bugs i have multi-megabyte tarballs attached)
+
+Regards Ronny
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values
new file mode 100644
index 0000000..a9cd364
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values
@@ -0,0 +1,11 @@
+Alt-id: <1247313294.7701.60.camel@localhost>
+
+
+Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 13:54:54 +0200
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body
new file mode 100644
index 0000000..debd486
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body
@@ -0,0 +1,95 @@
+On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > 1. is there any way to aggregate over multiple public branches in order
+> > > > to get the complete bug state
+> > > 
+> > > Keeping the bug data with the source helps synchronize bug state and
+> > > source code.  Bug state in branch A may not apply to branch B.  Some
+> > > people like to weaken this source-bug linkage by keeping their bugs in
+> > > a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+> > > currently supports this workflow).  It sounds like you want to move
+> > > from "bugs with code" to "bugs and code in separate branches".  We
+> > > don't have an easy way to do that in BE at the moment, since
+> > > version-control systems like Git have a single working branch at a
+> > > time (I think :p).  What VCS are you using as a backend?
+> >
+> > the basic idea is to take a look at all public branches (for exaple all
+> > on lp/bitbucket/github) in order to tell the user of a webinterface that
+> > bug foo is fixed in branch xyz, and if its merged to the main branch
+> 
+> Hmm.  
+> 
+> > > > 2. is there any model for storing bigger files at a central place (for
+> > > > some of my bugs i have multi-megabyte tarballs attached)
+> > > 
+> > >   be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > Then to grab the tarball, you'd use:
+> > >   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > to grab it.
+> > so the basic idea is to do it completely self-managed
+> 
+> Well, it's going to be managed by somebody ;).  So far I'm not
+> convinced enough for the manager to be me, so I'm suggesting it be you
+> :p.
+> 
+> > and have have heterogenous sources of extended data?
+> 
+> I assume "extended data" here refers to your tarballs.  What sort of
+> homogenous source did you have in mind?  The comment body is currently
+> just a binary blob for non-text/* types, otherwise it's text in
+> whatever encoding you've configured.
+some kind of common upload target for a single project in order to have
+more reliable sources of stuff thats related to bugs but doesnt fit into
+the normal repository
+
+
+> 
+> On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> > 
+> > > i want to see the combination of the bug data of all branches
+> > 
+> > How is a tool to determine the set of “all branches”? The distributed
+> > VCS model means that set is indeterminate.
+> 
+> He could just make a list of branches he likes.
+> 
+> Ronny, are you looking to check bug status across several repos on the
+> fly, or periodically run something (with cron, etc.) to update a
+> static multi-repo summary?
+on the fly access
+
+> 
+> The easiest implementation I can think of would be to keep local
+> branches (on whatever computer is hosting your web interface)
+> following your favorite repos.
+>   proxectX/
+>   |-- repoA
+>   |-- repoB
+>   `-- repoC
+> You'd pull upstream changes with a cron job.
+> Listing bugs would be something along the lines of
+>   projectX$ for repo in *
+>             do
+>               pushd $repo
+>               be list
+> 	      popd
+>             done | sort | uniq
+> Then to show bug status you would have something like
+>   projectX$ for repo in *
+>             do
+>               echo $repo
+>               pushd $repo
+>               be show ${BUGID}
+>               popd
+>             done
+> For a web frontend, you'd want to translate that to python/libbe.
+> 
+
+yes, the idea is to get a web fontend for multiple branches 
+and maybe a local gtk fontend for local multi-branch setups
+
+for some of my projects i have n local and m remote repos, and merging
+is not always intended soonish
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values
new file mode 100644
index 0000000..5a64ee0
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values
@@ -0,0 +1,14 @@
+Alt-id: <1247433610.14803.3.camel@localhost>
+
+
+Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 12 Jul 2009 23:20:10 +0200
+
+
+In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body
new file mode 100644
index 0000000..5f55127
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body
@@ -0,0 +1,87 @@
+On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > 1. is there any way to aggregate over multiple public branches in order
+> > > to get the complete bug state
+> > 
+> > Keeping the bug data with the source helps synchronize bug state and
+> > source code.  Bug state in branch A may not apply to branch B.  Some
+> > people like to weaken this source-bug linkage by keeping their bugs in
+> > a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+> > currently supports this workflow).  It sounds like you want to move
+> > from "bugs with code" to "bugs and code in separate branches".  We
+> > don't have an easy way to do that in BE at the moment, since
+> > version-control systems like Git have a single working branch at a
+> > time (I think :p).  What VCS are you using as a backend?
+>
+> the basic idea is to take a look at all public branches (for exaple all
+> on lp/bitbucket/github) in order to tell the user of a webinterface that
+> bug foo is fixed in branch xyz, and if its merged to the main branch
+
+Hmm.  
+
+> > > 2. is there any model for storing bigger files at a central place (for
+> > > some of my bugs i have multi-megabyte tarballs attached)
+> > 
+> >   be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > Then to grab the tarball, you'd use:
+> >   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > to grab it.
+> so the basic idea is to do it completely self-managed
+
+Well, it's going to be managed by somebody ;).  So far I'm not
+convinced enough for the manager to be me, so I'm suggesting it be you
+:p.
+
+> and have have heterogenous sources of extended data?
+
+I assume "extended data" here refers to your tarballs.  What sort of
+homogenous source did you have in mind?  The comment body is currently
+just a binary blob for non-text/* types, otherwise it's text in
+whatever encoding you've configured.
+
+On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> 
+> > i want to see the combination of the bug data of all branches
+> 
+> How is a tool to determine the set of “all branches”? The distributed
+> VCS model means that set is indeterminate.
+
+He could just make a list of branches he likes.
+
+Ronny, are you looking to check bug status across several repos on the
+fly, or periodically run something (with cron, etc.) to update a
+static multi-repo summary?
+
+The easiest implementation I can think of would be to keep local
+branches (on whatever computer is hosting your web interface)
+following your favorite repos.
+  proxectX/
+  |-- repoA
+  |-- repoB
+  `-- repoC
+You'd pull upstream changes with a cron job.
+Listing bugs would be something along the lines of
+  projectX$ for repo in *
+            do
+              pushd $repo
+              be list
+	      popd
+            done | sort | uniq
+Then to show bug status you would have something like
+  projectX$ for repo in *
+            do
+              echo $repo
+              pushd $repo
+              be show ${BUGID}
+              popd
+            done
+For a web frontend, you'd want to translate that to python/libbe.
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values
new file mode 100644
index 0000000..dbdb347
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values
@@ -0,0 +1,14 @@
+Alt-id: <20090711152507.GA18461@mjolnir.home.net>
+
+
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 11:25:07 -0400
+
+
+In-reply-to: e520239c-8d69-4ff6-b1bd-0c2f74366200
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body
new file mode 100644
index 0000000..cc3cff3
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body
@@ -0,0 +1,37 @@
+On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> 
+> > i want to see the combination of the bug data of all branches
+> 
+> What is your definition of ???all branches???? When I'm working with
+> distributed VCS, I create branches wherever I feel like, and the VCS
+> tool doesn't have some central registry of branches to keep up to date.
+> 
+> How is a tool to determine the set of ???all branches???? The distributed
+> VCS model means that set is indeterminate.
+
+In the first main Ronny spoke about "public" branches. To me it means that
+if a branch is public, he should like to have a status of that branch.
+
+We all agree (probably ;-) ) that tha main branch is the "right" branch, but
+as I see it, Ronny's question has some logic.
+I'd like to know that a certain bug is fixed in a certain branch, also if it
+is still not merged in the main branch, for various reason (ie I am interested
+in the solution since the bug stop my work) 
+
+Imagine it like a rss feed aggregator: in one place there are all the bugs of
+all the branches that the developers make avaible to the public with 
+a repository. This can make easier the life to who want to try a something
+since he know what branch he must check out, instead of checking all the 
+branch he can find to test if he get what is looking for.
+
+Unluckyly I have no idea how to solve it. :-(
+
+bye
+Gianluca
+ 
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values
new file mode 100644
index 0000000..28fe7dc
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values
@@ -0,0 +1,14 @@
+Alt-id: <20090713085859.GA21800@grys.it>
+
+
+Author: Gianluca Montecchi <gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 10:58:59 +0200
+
+
+In-reply-to: e520239c-8d69-4ff6-b1bd-0c2f74366200
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body
new file mode 100644
index 0000000..93f082b
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body
@@ -0,0 +1,33 @@
+On Sat, 2009-07-11 at 23:34 +1000, Ben Finney wrote:
+> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> 
+> > the basic idea is to take a look at all public branches (for exaple
+> > all on lp/bitbucket/github) in order to tell the user of a
+> > webinterface that bug foo is fixed in branch xyz, and if its merged to
+> > the main branch
+> 
+> I don't understand. The state of the bug in the main branch is right
+> there in the main branch; if it's not fixed there, it's not fixed there.
+> If it's merged in from a different branch, the bug state follows all the
+> other changes when they come in.
+> 
+> Can you give an example of what would be done differently?
+> 
+i want to see the combination of the bug data of all branches
+
+for example
+
+i got bug
+its fixed in the branch "something"
+its not fixed/merged to "main"
+
+now something like a website should tell me, this bug has been fixed in
+branch xyz and the fix is not yet merged into main
+
+
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values
new file mode 100644
index 0000000..a79837f
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values
@@ -0,0 +1,14 @@
+Alt-id: <1247320857.7701.67.camel@localhost>
+
+
+Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 16:00:57 +0200
+
+
+In-reply-to: 0f60a148-7024-44bd-bbed-377cbece9d1b
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body
new file mode 100644
index 0000000..3b417be
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body
@@ -0,0 +1,27 @@
+On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > 1. is there any way to aggregate over multiple public branches in order
+> > to get the complete bug state
+> 
+> Keeping the bug data with the source helps synchronize bug state and
+> source code.  Bug state in branch A may not apply to branch B.  Some
+> people like to weaken this source-bug linkage by keeping their bugs in
+> a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+> currently supports this workflow).  It sounds like you want to move
+> from "bugs with code" to "bugs and code in separate branches".  We
+> don't have an easy way to do that in BE at the moment, since
+> version-control systems like Git have a single working branch at a
+> time (I think :p).  What VCS are you using as a backend?
+the basic idea is to take a look at all public branches (for exaple all
+on lp/bitbucket/github) in order to tell the user of a webinterface that
+bug foo is fixed in branch xyz, and if its merged to the main branch
+> 
+> > 2. is there any model for storing bigger files at a central place (for
+> > some of my bugs i have multi-megabyte tarballs attached)
+> 
+>   be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> Then to grab the tarball, you'd use:
+>   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> to grab it.
+so the basic idea is to do it completely self-managed and have have
+heterogenous sources of extended data?
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values
new file mode 100644
index 0000000..00fe043
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values
@@ -0,0 +1,14 @@
+Alt-id: <1247317985.7701.63.camel@localhost>
+
+
+Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 15:13:05 +0200
+
+
+In-reply-to: 13012b22-2d02-444c-87c0-8cf0f17137ae
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body
new file mode 100644
index 0000000..0263fbb
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body
@@ -0,0 +1,22 @@
+Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+
+> i want to see the combination of the bug data of all branches
+
+What is your definition of “all branches”? When I'm working with
+distributed VCS, I create branches wherever I feel like, and the VCS
+tool doesn't have some central registry of branches to keep up to date.
+
+How is a tool to determine the set of “all branches”? The distributed
+VCS model means that set is indeterminate.
+
+-- 
+ \         “Pinky, are you pondering what I'm pondering?” “I think so, |
+  `\    Brain, but I find scratching just makes it worse.” —_Pinky and |
+_o__)                                                       The Brain_ |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values
new file mode 100644
index 0000000..2adef07
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values
@@ -0,0 +1,14 @@
+Alt-id: <87zlbbl128.fsf@benfinney.id.au>
+
+
+Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 12 Jul 2009 00:57:35 +1000
+
+
+In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7
+
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body
new file mode 100644
index 0000000..9fb10bc
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body
@@ -0,0 +1,26 @@
+On Sat, Jul 11, 2009 at 11:31:34PM +1000, Ben Finney wrote:
+> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> 
+> > 1. is there any way to aggregate over multiple public branches in
+> > order to get the complete bug state
+> 
+> The bug state is as complete as the source code state. It's exactly as
+> aggregated as the rest of the source code; the ???complete bug state???
+> would be the integration branch where you merge all the feature branches
+> and bug-fix branches together.
+> 
+> If instead you want bugs to *not* be tightly linked with the rest of the
+> source code state, it seems you don't want a distributed bug tracker
+> like Bugs Everywhere.
+
+"the complete bug state" probably means that he want to know (and in some way
+to publish it) that the bug "xyz" is fixed and merged in main while bug "abc"
+is fixed but only in branch "123" and bug "def" is still open in branch "456"
+
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values
new file mode 100644
index 0000000..fc2560e
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values
@@ -0,0 +1,14 @@
+Alt-id: <20090713090341.GB21800@grys.it>
+
+
+Author: Gianluca Montecchi <gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 11:03:41 +0200
+
+
+In-reply-to: 1f9f60de-ba37-42bc-a1c0-dc062ef255e1
+