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. Sorry to differ a bit from the format, but I think it is important to explain and get things sorted here. Keep it constructive! Many thanks to Ed for the valueable comments. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
