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, 77 insertions, 0 deletions

diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body
new file mode 100644
index 0000000..d2ef28c
--- /dev/null
+++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body
@@ -0,0 +1,77 @@
+Those are beautiful templates -- can you share those?  I'd love to
+study the HTML and CSS behind them.
+
+On Sat, Feb 7, 2009 at 5:48 PM, Steve Losh <steve@stevelosh.com> wrote:
+> Hey Chris, thanks for the comments.
+>
+>>
+>> My initial impression is that this looks good enough already to merge as
+>> a replacement for the turbogears site.  What does everyone else think?
+>>
+>
+> I'm not quite sure it's there yet.  There are a bunch of bugs I've got
+> marked as "beta" that I'd like to see fixed before it's ready for real use.
+>  Hopefully they shouldn't be too tough to fix.  You can point CFBE at itself
+> to see them.  :)
+>
+>> Could you explain a little about how you handle authorship of bug
+>> changes at the moment, and if it looks plausible to try making it
+>> multiuser?  (Having it handle more than one "user" logged in at once.)
+>>
+>
+> That's something I need advice on.  Right now CFBE is pretty much only
+> suitable for local use - you check out whatever you're working on and use it
+> as a local interface to the bugs in the repository.  Change those, check in,
+> etc.  It's effectively just a pretty version of the command line be tool.
+>
+> I haven't used CherryPy's session/authentication support before.  This might
+> be a good time for me to learn.  One way it might be able to handle multiple
+> users hitting a central server:
+>
+> * Each user has to register with the server and be approved by an admin.
+> * Each account would be mapped to a contributor string, the same one that
+> would show up if you were going to commit to the repository.
+> * Once you have an account, you'd login to make any changes.
+>
+>
+> Aside from all that, I'm a little fuzzy on how a centralized interface to a
+> distributed bug tracking system should work.  A read-only interface to a
+> central "main" repository would be easy.  Run the server in read-only mode
+> pointing at the main repository.  People can use it to look at the bugs in
+> the tip of that repository.
+>
+> If it's not read-only, what happens when a user changes/adds/whatevers a
+> bug?  Should CFBE commit that change to the repository right then and there?
+>  Should it never commit, just update the bugdir and let the commits happen
+> manually?
+>
+> What happens when you have multiple branches for a repository?  Should there
+> be one CFBE instance for each branch, or a single one that lets you switch
+> between branches (effectively switching between revisions)?
+>
+> Those are the kind of things that don't really apply when CFBE is just a
+> local interface to a single repository.  If anyone has any advice on how a
+> multi-user interface should work I'd love to hear it!
+>
+> --
+> Steve Losh
+> http://stevelosh.com/
+>
+>
+> _______________________________________________
+> Be-devel mailing list
+> Be-devel@bugseverywhere.org
+> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
+>
+
+
+
+-- 
+Matthew Wilson
+matt@tplus1.com
+http://tplus1.com
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel