My personal experience shows that pointing reponsibilities creates community fragmentation.
All the committers are responsible for all the code: if we start asking permissions to one another to modify code in the "area" where others people is responsible, the development performance drops.
Don't go there.
I strongly agree with Stefano here, but would like to add that officially assigning code responsibilities conflicts with the Apache community development spirit, or at least with my understanding of it.
First of all, the Slide project is not a development department in some company. It's a community project maintained and developed by volunteers (even though it might have looked like a department of Software AG for the last year ;-) ). Contributors come and go. As I joined the project, 90% of the commits came from Remy and Dirk. Remy was working on the kernel, the WebDAV layer and the tomcat integration mostly, while Dirk was working on the client stuff and the stores. Both are no longer working on Slide.
In every project there are areas of the code that some committers know better than others, but that is not the same as responsibility or ownership. If a committer that is working mostly on the webdav layer wants to fix a bug in a store implementation he should not first have to ask some other committer for permission, nor should he delegate the bug fix to that committer. He commits the fix, the mailing list gets the commit message, and ideally every active/interested contributor reviews the change. If a committer doesn't understand the rationale or implementation of the change, he responds to the commit message and triggers a discussion on the dev-list. If a commiter thinks the fix is flawed, he vetoes it, meaning that it must be reverted ASAP. This is called "Commit Then Review" [1] and is an important aspect of the development model used across all ASF projects that I'm involved with, and it definitely was always used by the Slide subproject.
That is not to say that you should not ask others about their opinion before committing changes. If you're not sure about a change, or the change might have a large impact on the code base, you definitely should try to collect some opinions on the list.
Assigning responsibilities discourages committers to work on areas of the code base that they do not "own". The contrary (collective code ownership) should be the goal, because it is the best fit with the community-driven, volunteer-based development process we have here. Some will say that collective code ownership is the best model even for traditional, commercial software development :-)
-chris
[1] http://incubator.apache.org/learn/glossary.html#CommitThenReview
On 18 Nov 2003, at 01:20, Oliver Zeigermann wrote:
For the release and also for the people contributing questions or patches there should be someone to address directly for each part of the code.
At least for the stores, the client, the webdav layer and of course the kernel there must be at least one committer in charge.
Responsibilities I presume because of what I perceive as the status quo are (feel free to correct me here):
Peter Nevermann: - kernel org.apache.slide.security - kernel org.apache.slide.structure - Webdav layer
J�rgen Pill: - Tests - kernel org.apache.slide.transaction - Webdav layer
Martin Wallmer: - kernel org.apache.slide.search - Webdav layer
Ingo Brunberg: - Client library
Oliver Zeigermann: - stores - kernel org.apache.slide.store - kernel org.apache.slide.util
What about these kernel packages? Anybody feeling responsible? - org.apache.slide.authenticate - org.apache.slide.common - org.apache.slide.content - org.apache.slide.lock - org.apache.slide.macro
If there is no one who feels responsible for these, I'd propose it is subject to all committers.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
