.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body

   1 On Thu, Jun 25, 2009 at 10:23:04AM -0400, Steve Losh wrote:
   2 > I'm still curious as to what people think the role of a web interface like
   3 > this should be. When I wrote it I meant it as a single-user interface like
   4 > the command line one. It could definitely work as a public, read-only
   5 > interface too.
   6
   7 I think the multi-user/public is the way to go.  I'd also like to see
   8 a procmail-able script to handle multi-user/public access via email,
   9 which would have all the same issues we're worrying about here.
  10
  11 On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote:
  12 > I haven't used CherryPy's session/authentication support before.  This
  13 > might be a good time for me to learn.  One way it might be able to handle
  14 > multiple users hitting a central server:
  15 >
  16 > * Each user has to register with the server and be approved by an admin.
  17 > * Each account would be mapped to a contributor string, the same one that
  18 > would show up if you were going to commit to the repository.
  19 > * Once you have an account, you'd login to make any changes.
  20
  21 This sounds good to me.  Yay spam reduction ;).
  22
  23 > If it's not read-only, what happens when a user changes/adds/whatevers a
  24 > bug?  Should CFBE commit that change to the repository right then and
  25 > there?  Should it never commit, just update the bugdir and let the commits
  26 > happen manually?
  27
  28 On Thu, Jun 25, 2009 at 10:23:04AM -0400, Steve Losh wrote:
  29 > One commit per change? Commit every X minutes if necessary?
  30
  31 On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote:
  32 > What happens when you have multiple branches for a repository?  Should
  33 > there be one CFBE instance for each branch, or a single one that lets you
  34 > switch between branches (effectively switching between revisions)?
  35
  36 There are interesting discussions about the role of distributed
  37 bugtracking here (I'm sure there are others):
  38   http://lwn.net/Articles/281849/
  39   http://community.livejournal.com/evan_tech/248736.html
  40
  41 Personally, I've never done much cherry-picking or anything that would
  42 require me to determine exactly which parts of someone's work I want
  43 and which I don't want.  I just merge someone's head and edit out the
  44 bits I don't like, a process that also works well for our current
  45 "commit however you want" BE development model ;).  Maybe that just
  46 shows that I only work on minor branches of small projects :p.  In the
  47 absence of big-project advice, I think we just limit the web front end
  48 to our current model, and let the web interface commit however it
  49 wants as well ;).  +1 for adding a <commit> button to the web
  50 interface ;).
  51
  52 One caveat about a multi-user interface would be that it would allow
  53 the casual users to commit bugs about whatever version they had
  54 installed onto the head of the public-bug branch.  In order to figure
  55 out what version of the project they were talking about, the project
  56 should have a way for the user to get a unique version string, ideally
  57 be the bzr-revision-id/git-commit/etc. of the commit for the version
  58 they were using.  This would allow developers to determine what branch
  59 to work on with the bug fix, and what branches needed to pull the
  60 eventual fix.  If the initially reported buggy version wasn't actually
  61 the root of the bug, oh well :p.  Material for a later related bug
  62 report or a reopen.
  63
  64 --
  65 This email may be signed or encrypted with GPG (http://www.gnupg.org).
  66 The GPG signature (if present) will be attached as 'signature.asc'.
  67 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
  68
  69 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt