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

2 files changed, 59 insertions, 0 deletions

diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body
new file mode 100644
index 0000000..27dca1e
--- /dev/null
+++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body
@@ -0,0 +1,45 @@
+On Saturday 04 July 2009 02:31:26 Chris Ball wrote:
+> Hi Gianluca,
+>
+>    > As i said in a previous mail, I am working on a "html" command
+>    > for be.  The goal is to be able to do something like "be html
+>    > /web/page" to have in the /web/page directory some static html
+>    > pages that basically are the dump of the be repository, much like
+>    > ditz have. This will enable a simple and fast publish of the bus
+>    > list and details on the web, at least in read only mode.
+>
+> It might be a good idea for "be html" to use the CherryPy web interface
+> that Steve is working on.  The command could start up the CherryPy app
+> and scrape all of the available pages to get a stand-alone dump; this
+> would avoid having to keep two (okay, more than two at this point)
+> separate sets of HTML templates in the source tree.  What do you think?
+
+It can be do, but this implies that CherryPy must be installed and configured, 
+a thing that I don't want to impose. My idea is to offer a simpler way to have 
+some html pages, where you just need to have BE installed.
+
+My very first implementation was a script that parse directly the .be directory 
+to build the pages, without BE itself installed.
+
+
+>    > 2) I see that every command is implemented with a python file in
+>    > the becommand dir. For a better code, I'd like to split the
+>    > command implementation into two files: a file that contain the
+>    > actual code and a second file that have the html related part,
+>    > any problem with this ? I don't like to have the html part and
+>    > the code part in one big and unreadable file.
+>
+> I agree that becommands/*.py commands should not contain any HTML
+> layout code.  Putting it somewhere else instead sounds fine.
+
+I am in doubt with the "somewhere else", since for now I put the html template 
+into a separate file in the same directory. Suggestion ?
+
+thanks
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values
new file mode 100644
index 0000000..1bf2dc4
--- /dev/null
+++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values
@@ -0,0 +1,14 @@
+Alt-id: <200907062246.54804.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 06 Jul 2009 22:46:54 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: b900f7fd-bab6-48c4-922c-a051f933da58
+