1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
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
|
