diff options
author | Chris Ball <cjb@laptop.org> | 2009-07-23 17:49:13 -0400 |
---|---|---|
committer | Chris Ball <cjb@laptop.org> | 2009-07-23 17:49:13 -0400 |
commit | 6a639574fa95e50f82fa3052e5524b961295a7ab (patch) | |
tree | b498654ed1dcbdbba94605292c280c883c5e9faa /.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body | |
parent | 5e249abfee7273c79640c4211607a6b4bf7b374c (diff) | |
parent | caf0111d9c571ac268c235880e6d18fa512e9efa (diff) | |
download | bugseverywhere-6a639574fa95e50f82fa3052e5524b961295a7ab.tar.gz |
Merge large rework from W. Trevor King.
Diffstat (limited to '.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body')
-rw-r--r-- | .be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body | 69 |
1 files changed, 69 insertions, 0 deletions
diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body new file mode 100644 index 0000000..ae6a5fe --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body @@ -0,0 +1,69 @@ +On Thu, Jun 25, 2009 at 10:23:04AM -0400, Steve Losh wrote: +> I'm still curious as to what people think the role of a web interface like +> this should be. When I wrote it I meant it as a single-user interface like +> the command line one. It could definitely work as a public, read-only +> interface too. + +I think the multi-user/public is the way to go. I'd also like to see +a procmail-able script to handle multi-user/public access via email, +which would have all the same issues we're worrying about here. + +On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote: +> 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. + +This sounds good to me. Yay spam reduction ;). + +> 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? + +On Thu, Jun 25, 2009 at 10:23:04AM -0400, Steve Losh wrote: +> One commit per change? Commit every X minutes if necessary? + +On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote: +> 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)? + +There are interesting discussions about the role of distributed +bugtracking here (I'm sure there are others): + http://lwn.net/Articles/281849/ + http://community.livejournal.com/evan_tech/248736.html + +Personally, I've never done much cherry-picking or anything that would +require me to determine exactly which parts of someone's work I want +and which I don't want. I just merge someone's head and edit out the +bits I don't like, a process that also works well for our current +"commit however you want" BE development model ;). Maybe that just +shows that I only work on minor branches of small projects :p. In the +absence of big-project advice, I think we just limit the web front end +to our current model, and let the web interface commit however it +wants as well ;). +1 for adding a <commit> button to the web +interface ;). + +One caveat about a multi-user interface would be that it would allow +the casual users to commit bugs about whatever version they had +installed onto the head of the public-bug branch. In order to figure +out what version of the project they were talking about, the project +should have a way for the user to get a unique version string, ideally +be the bzr-revision-id/git-commit/etc. of the commit for the version +they were using. This would allow developers to determine what branch +to work on with the bug fix, and what branches needed to pull the +eventual fix. If the initially reported buggy version wasn't actually +the root of the bug, oh well :p. Material for a later related bug +report or a reopen. + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt |