1 |
Luca Barbato wrote: |
2 |
|
3 |
> Edward Catmur wrote: |
4 |
>> On Sat, 2006-06-24 at 13:05 +0200, Luca Barbato wrote: |
5 |
>>> (from critics) |
6 |
>>> - What is wrong with the model (each point 2 lines at least, 4 at most) |
7 |
>>> - What you'd do as alternative as the criticized point ( 2 lines again) |
8 |
> |
9 |
> Let me reformat a bit |
10 |
>> |
11 |
> |
12 |
> Critic 1 |
13 |
>> * Simplicity: The FAQ claims that Sunrise is simpler than Bugzilla. It |
14 |
>> is - for users. Contributing is a lot more involved than with Bugzilla; |
15 |
>> Sunrise is supposed to be about making contributing easier. |
16 |
> |
17 |
> Reply 1 |
18 |
>> - Admit this in the FAQ. Where possible, write svn wrappers to make the |
19 |
>> contributing process easier. |
20 |
|
21 |
I have added something to the answer in question, if it does not go far |
22 |
enough I would appreciate a better rewording from you :) |
23 |
"But in contrast to that it requires more knowledge and tools to get |
24 |
something into sunrise - more work for contributors. Also contributors have |
25 |
to get their ebuilds reviewed before committing - bugzilla is easier here." |
26 |
|
27 |
For wrappers: I am working on a svncommit.sh to generate the digest and svn |
28 |
commit the ebuilds. This is certainly high on the TODO list :) |
29 |
|
30 |
> Critic 2 |
31 |
>> * Security (from malicious contributors): Glad to see layman will only |
32 |
>> track the reviewed/ tree; still, anyone who checks out the sunrise/ tree |
33 |
>> (and has it in PORTDIR_OVERLAY) is vulnerable. |
34 |
> |
35 |
> Reply 2a |
36 |
>> - Remove from the examples any suggestion that one should check out the |
37 |
>> whole tree when contributing. |
38 |
|
39 |
A contributor needs the whole tree, because of the scripts/ and the |
40 |
profiles/ directory as well as skel.ChangeLog. For 2b I have added an |
41 |
explicit warning, I think it covers this as well. |
42 |
|
43 |
> Reply 2b |
44 |
> - Point out that one should not svn up sunrise/ as part of updating |
45 |
> Portage. |
46 |
|
47 |
right, I added the following: |
48 |
"The copy of the sunrise you will checkout here is '''not reviewed'''. |
49 |
Handle with extreme care. Do not use this as your PORTDIR_OVERLAY! Keep |
50 |
using your reviewed layman copy for PORTDIR_OVERLAY." |
51 |
> |
52 |
> Reply 2c |
53 |
> - sunrise/playground won't let anonymous fetch. |
54 |
Yeah, this is certainly easy to do and increases safety. I have been bugging |
55 |
jokey about this already :) |
56 |
|
57 |
> Critic 3 |
58 |
>> * Conflicts between contributors (technical): Alice adds an ebuild; Bob |
59 |
>> makes a change; Alice makes another change and discovers it conflicts |
60 |
>> with Bob's change in the repo. Alice has not used subversion and doesn't |
61 |
>> know how to resolve conflicts. |
62 |
> |
63 |
> Reply 3a |
64 |
> - People are supposed to learn svn in order to contribute. |
65 |
since we use the IRC channel for contributing, I think this is a non-isssue |
66 |
because devs in the IRC channel know subversion and can help out. Learning |
67 |
by doing is preferred. |
68 |
|
69 |
> Reply 3b |
70 |
> - Tutorials will be provided about conflict resolution |
71 |
see #3a, I do not want to write too many docs that are not often needed and |
72 |
easily explained in IRC. |
73 |
|
74 |
> Critic 4 |
75 |
>> * Conflicts between contributors (social): Alice adds an ebuild; Bob |
76 |
>> makes a (maybe "obvious") change; Alice thinks the change is incorrect, |
77 |
>> and, feeling that the ebuild is her property, reverts the change. A |
78 |
>> revert war erupts. Many casualties. |
79 |
> |
80 |
> Reply 4a |
81 |
>> - Create a social structure to enable Alice and Bob to communicate and |
82 |
>> resolve their differences of opinion. Forums? Wiki? IRC? Bugzilla? I |
83 |
>> would argue there should be One True location for this to occur; not |
84 |
>> bugzilla (bugspam); not IRC (impermanence). |
85 |
IRC is certainly a good and direct way of doing this and it has worked in |
86 |
the past for us, when we already had a similar conflict. Now you say that |
87 |
IRC is impermanent, where do you see the problem, can you elaborate that a |
88 |
bit for me, please? We are open here. Currently there is no forced way of |
89 |
communication - everyone can chose how to communicate himself. |
90 |
|
91 |
> Reply 4b |
92 |
> - ban warmongers. |
93 |
this can always be done, but it is a last resort that is hopefully not |
94 |
needed. Of course when someone behaves badly action will be taken. |
95 |
|
96 |
> Critic 5 |
97 |
>> * More to keep track of: With bugzilla you have a single URL, from which |
98 |
>> you receive threaded email updates. Sunrise adds /two/ svn directories |
99 |
>> plus whatever is used for discussion. |
100 |
>> - Create a summary page that links to bugzilla and discussions, and |
101 |
>> tracks versions and changes, and all other relevant information. Allow |
102 |
>> (require?) contributors to subscribe to email updates from the summary |
103 |
>> page. |
104 |
Yeah, this is also on our TODO list, currently we have a script for that: |
105 |
scripts/create-stats.sh - it currently lists only bug entries and herds, |
106 |
devs on CC for packages in the overlay. A more extensive version of that |
107 |
needs to be put on a web page, right. |
108 |
For updates: |
109 |
Every ebuild-committer is required to CC to the bug, important ebuild |
110 |
updates need to be mentioned on the bug, I think a second |
111 |
update/notification system would be overkill here and leave out people that |
112 |
only use bugzilla. |
113 |
|
114 |
> Ed if you think this doesn't show your ideas please send another using |
115 |
> this format. |
116 |
I changed some things back where I wanted to answer Ed directly. Sorry to |
117 |
differ a bit from the format, but I think it is important to explain and |
118 |
get things sorted here. Keep it constructive! |
119 |
|
120 |
Many thanks to Ed for the valueable comments. |
121 |
|
122 |
Regards, |
123 |
Stefan |
124 |
|
125 |
-- |
126 |
gentoo-dev@g.o mailing list |