Russell Blau ha scritto:
OK, nobody said anything [...]
As usual...
Policy should be inverted: patches + reviews = commits
Fewer problems (regressions, typos, bad code, 100 commits for 1 problem, strange ideas, etc...)
And, especially, so the dev team work as unit and do progress.
Due to mailing-list use, you are working 99.9% alone in rewrite branch. I am sorry, you undertook a lot of work.
I am sorry, too, Francesco, but I don't entirely understand your comments. Could you explain in more detail how you want the team to work? Anything that would lead to more cooperation and fewer bugs would be good.
Current state is this mailing-list is just ignored, almost no talks about the project and its development. Am I wrong? SVN commits are coming and there isn't certainty they are checked. Nobody know who is present, who is away...
We can try to force patch review and only to commit reviewed patches. This should improve code quality and cooperation, without compromising a lot development speed.
I can indicate some open source projects that take care of the code in this way.
While I am at it... Why not add a mailing-list for SVN log notification only? Looks bad mixed with the rest (http://lists.wikimedia.org/pipermail/pywikipedia-l/2009-January/thread.html). "pywikipedia-l" might be renamed "pywikipedia-devel", and continue to receive bug tracker data.