aboutsummaryrefslogtreecommitdiffstats
path: root/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a
diff options
context:
space:
mode:
authorW. Trevor King <wking@drexel.edu>2009-07-21 15:22:09 -0400
committerW. Trevor King <wking@drexel.edu>2009-07-21 15:22:09 -0400
commit9ef8e376212786d8a99cfa19bfcd9c6e70735d0a (patch)
tree50d05dc3394845e1d1fd172be9125102d07ad43e /.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a
parent949b17853e384d4bce85a2ab0b29cf28375465aa (diff)
downloadbugseverywhere-9ef8e376212786d8a99cfa19bfcd9c6e70735d0a.tar.gz
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
Diffstat (limited to '.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a')
-rw-r--r--.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body69
-rw-r--r--.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/values14
2 files changed, 83 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
diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/values
new file mode 100644
index 0000000..2fa8470
--- /dev/null
+++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/values
@@ -0,0 +1,14 @@
+Alt-id: <20090625154734.GA19441@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 25 Jun 2009 11:47:34 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d
+