Luca Barbato wrote:
> Edward Catmur wrote:
>> On Sat, 2006-06-24 at 13:05 +0200, Luca Barbato wrote:
>>> (from critics)
>>> - What is wrong with the model (each point 2 lines at least, 4 at most)
>>> - What you'd do as alternative as the criticized point ( 2 lines again)
>
> Let me reformat a bit
>>
>
> Critic 1
>> * Simplicity: The FAQ claims that Sunrise is simpler than Bugzilla. It
>> is - for users. Contributing is a lot more involved than with Bugzilla;
>> Sunrise is supposed to be about making contributing easier.
>
> Reply 1
>> - Admit this in the FAQ. Where possible, write svn wrappers to make the
>> contributing process easier.
I have added something to the answer in question, if it does not go far
enough I would appreciate a better rewording from you :)
"But in contrast to that it requires more knowledge and tools to get
something into sunrise - more work for contributors. Also contributors have
to get their ebuilds reviewed before committing - bugzilla is easier here."
For wrappers: I am working on a svncommit.sh to generate the digest and svn
commit the ebuilds. This is certainly high on the TODO list :)
> Critic 2
>> * Security (from malicious contributors): Glad to see layman will only
>> track the reviewed/ tree; still, anyone who checks out the sunrise/ tree
>> (and has it in PORTDIR_OVERLAY) is vulnerable.
>
> Reply 2a
>> - Remove from the examples any suggestion that one should check out the
>> whole tree when contributing.
A contributor needs the whole tree, because of the scripts/ and the
profiles/ directory as well as skel.ChangeLog. For 2b I have added an
explicit warning, I think it covers this as well.
> Reply 2b
> - Point out that one should not svn up sunrise/ as part of updating
> Portage.
right, I added the following:
"The copy of the sunrise you will checkout here is '''not reviewed'''.
Handle with extreme care. Do not use this as your PORTDIR_OVERLAY! Keep
using your reviewed layman copy for PORTDIR_OVERLAY."
>
> Reply 2c
> - sunrise/playground won't let anonymous fetch.
Yeah, this is certainly easy to do and increases safety. I have been bugging
jokey about this already :)
> Critic 3
>> * Conflicts between contributors (technical): Alice adds an ebuild; Bob
>> makes a change; Alice makes another change and discovers it conflicts
>> with Bob's change in the repo. Alice has not used subversion and doesn't
>> know how to resolve conflicts.
>
> Reply 3a
> - People are supposed to learn svn in order to contribute.
since we use the IRC channel for contributing, I think this is a non-isssue
because devs in the IRC channel know subversion and can help out. Learning
by doing is preferred.
> Reply 3b
> - Tutorials will be provided about conflict resolution
see #3a, I do not want to write too many docs that are not often needed and
easily explained in IRC.
> Critic 4
>> * Conflicts between contributors (social): Alice adds an ebuild; Bob
>> makes a (maybe "obvious") change; Alice thinks the change is incorrect,
>> and, feeling that the ebuild is her property, reverts the change. A
>> revert war erupts. Many casualties.
>
> Reply 4a
>> - Create a social structure to enable Alice and Bob to communicate and
>> resolve their differences of opinion. Forums? Wiki? IRC? Bugzilla? I
>> would argue there should be One True location for this to occur; not
>> bugzilla (bugspam); not IRC (impermanence).
IRC is certainly a good and direct way of doing this and it has worked in
the past for us, when we already had a similar conflict. Now you say that
IRC is impermanent, where do you see the problem, can you elaborate that a
bit for me, please? We are open here. Currently there is no forced way of
communication - everyone can chose how to communicate himself.
> Reply 4b
> - ban warmongers.
this can always be done, but it is a last resort that is hopefully not
needed. Of course when someone behaves badly action will be taken.
> Critic 5
>> * More to keep track of: With bugzilla you have a single URL, from which
>> you receive threaded email updates. Sunrise adds /two/ svn directories
>> plus whatever is used for discussion.
>> - Create a summary page that links to bugzilla and discussions, and
>> tracks versions and changes, and all other relevant information. Allow
>> (require?) contributors to subscribe to email updates from the summary
>> page.
Yeah, this is also on our TODO list, currently we have a script for that:
scripts/create-stats.sh - it currently lists only bug entries and herds,
devs on CC for packages in the overlay. A more extensive version of that
needs to be put on a web page, right.
For updates:
Every ebuild-committer is required to CC to the bug, important ebuild
updates need to be mentioned on the bug, I think a second
update/notification system would be overkill here and leave out people that
only use bugzilla.
> Ed if you think this doesn't show your ideas please send another using
> this format.
I changed some things back where I wanted to answer Ed directly.
