On 19 Nov 2003, at 03:43, Christopher Lenz wrote:
Stefano Mazzocchi wrote: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
Amen :-)
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
