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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body
new file mode 100644
index 0000000..d8f14fc
--- /dev/null
+++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body
@@ -0,0 +1,32 @@
+Hello to everyone
+
+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.
+
+So I'd like to ask some question:
+1) is it ok to develop this command ? I know that this is not a fully featured 
+web interface, but I am sure that it can be usefull.
+
+I am open to suggestion about it of course.
+
+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'd like to hear other opinion about this.
+
+Thanks for now
+bye
+Gianluca
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel