I imported a few threads from the mailing list as wishlist bugs.

12c:uw: Bug aggregation.  Multi-repo meta-BE?
529:ow: How should we version BE?
2f0:aw: Static html report generation
22b:aw: Sorting targets chronologically
d99:aw: CherryPy interface "Cherry-flavored BE"
e08:aw: Interactive email interface

1 files changed, 32 insertions, 0 deletions

diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body
new file mode 100644
index 0000000..cf3c990
--- /dev/null
+++ b/.be/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