On 19 Nov 2003, at 04:20, Christopher Lenz wrote:
Oliver Zeigermann wrote:Christopher Lenz wrote: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.Completely agreed :) Maybe the misunderstanding lies in the definition of "responsibility".
Indeed, "responsibility" is far too strong for what you seem to be intending to express (IMHO).
Sorry, if my interpretation was misleading. Maybe "contact" would have been a better word. Does this settle it?
I would just drop the whole subject :-P
First, the primary "contact" for all questions regarding the code base is the dev-list. Second, the CVS repository has all the info you need *if* you really want to know exactly who has worked on the code in question. Additional information like the contributors page and the @author tags is also available, although these are often not actively maintained and can thus be misleading.
FYI, the Apache James project has voted to remove all @author tags from their Java source files [1]. One important reason for this motion was to further emphasize the feeling of collective code ownership. I guess every committer has had mails coming into his inbox from "clever" people who saw their name and address in the @author tag and decided to ask the person directly instead of the mailing list. Assigning responsibilities or even informally listing contacts hurts collective code ownership and thus the developer community, IMHO.
Avalon did the same and there was a discussion on Cocoon as well. the cocoon dev community decided to keep the @author tag for paying back new committers, but suggested them to stop using them after a while.
I personally keep receiving personal inquiries from "clever" people about some code I wrote years ago for jserv that went into tomcat or for ant and automatically believe that I should fix their bugs on that code (which I don't even remember I wrote).
Personal code ownership is bad. Recognition is good for new people coming in, as it gives a warm feeling and good visibility, but it should be kept as low as possible.
Assigning "contacts" to part of the code goes *exactly* in the opposite direction.
Let's not forget that apache values communities more than code. So, what we are trying to do here is not only to make Slide solid now, but allow a diverse and healty community to emerge and to keep the project moving when each one of us will have some other thing to do.
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
