.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body

   1 Those are beautiful templates -- can you share those?  I'd love to
   2 study the HTML and CSS behind them.
   3
   4 On Sat, Feb 7, 2009 at 5:48 PM, Steve Losh <steve@stevelosh.com> wrote:
   5 > Hey Chris, thanks for the comments.
   6 >
   7 >>
   8 >> My initial impression is that this looks good enough already to merge as
   9 >> a replacement for the turbogears site.  What does everyone else think?
  10 >>
  11 >
  12 > I'm not quite sure it's there yet.  There are a bunch of bugs I've got
  13 > marked as "beta" that I'd like to see fixed before it's ready for real use.
  14 >  Hopefully they shouldn't be too tough to fix.  You can point CFBE at itself
  15 > to see them.  :)
  16 >
  17 >> Could you explain a little about how you handle authorship of bug
  18 >> changes at the moment, and if it looks plausible to try making it
  19 >> multiuser?  (Having it handle more than one "user" logged in at once.)
  20 >>
  21 >
  22 > That's something I need advice on.  Right now CFBE is pretty much only
  23 > suitable for local use - you check out whatever you're working on and use it
  24 > as a local interface to the bugs in the repository.  Change those, check in,
  25 > etc.  It's effectively just a pretty version of the command line be tool.
  26 >
  27 > I haven't used CherryPy's session/authentication support before.  This might
  28 > be a good time for me to learn.  One way it might be able to handle multiple
  29 > users hitting a central server:
  30 >
  31 > * Each user has to register with the server and be approved by an admin.
  32 > * Each account would be mapped to a contributor string, the same one that
  33 > would show up if you were going to commit to the repository.
  34 > * Once you have an account, you'd login to make any changes.
  35 >
  36 >
  37 > Aside from all that, I'm a little fuzzy on how a centralized interface to a
  38 > distributed bug tracking system should work.  A read-only interface to a
  39 > central "main" repository would be easy.  Run the server in read-only mode
  40 > pointing at the main repository.  People can use it to look at the bugs in
  41 > the tip of that repository.
  42 >
  43 > If it's not read-only, what happens when a user changes/adds/whatevers a
  44 > bug?  Should CFBE commit that change to the repository right then and there?
  45 >  Should it never commit, just update the bugdir and let the commits happen
  46 > manually?
  47 >
  48 > What happens when you have multiple branches for a repository?  Should there
  49 > be one CFBE instance for each branch, or a single one that lets you switch
  50 > between branches (effectively switching between revisions)?
  51 >
  52 > Those are the kind of things that don't really apply when CFBE is just a
  53 > local interface to a single repository.  If anyone has any advice on how a
  54 > multi-user interface should work I'd love to hear it!
  55 >
  56 > --
  57 > Steve Losh
  58 > http://stevelosh.com/
  59 >
  60 >
  61 > _______________________________________________
  62 > Be-devel mailing list
  63 > Be-devel@bugseverywhere.org
  64 > http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
  65 >
  66
  67
  68
  69 --
  70 Matthew Wilson
  71 matt@tplus1.com
  72 http://tplus1.com
  73
  74 _______________________________________________
  75 Be-devel mailing list
  76 Be-devel@bugseverywhere.org
  77 http://void.printf.net/cgi-bin/mailman/listinfo/be-devel