I really wonder if we have a misunderstanding here.Perhaps so. From the perspective of a non-committer, and rare contributor (with an ongoing consideration of adopting Slide), I would emphasize that the project is *open source*. Since people are not getting paid to contribute to the project per-se, the safe assumption is that they can stop contributing at any time.
When patches are submitted by the likes of me (a non-committer), they are supposed to be reviewed by two committers, aren't they? How can that happen if everyone is worried about just "their" part of the "playground."
One of the absolutely fascinating things about open source projects - at least the good ones - is that a sufficient number of test cases must exist so that complete strangers can suggest changes to the code, and have a fairly high confidence level that their changes are correct, by virtue of the test cases all passing. In other words, the test cases should demonstrate this mastery, not a particular person.
Undoubtedly, there may be one person who implicitly has the most knowledge about a particular area of the project. Anyone who's curious can find out who that is with a quick trip through the CVS archives, the mail archive, or the Bugzilla reports. The robustness and reliability of the project, though, comes from the assumption that more than one person *could* assume that role, in the absence of the person currently demonstrating their mastery.
I think it is fine to have an implicit association between people with parts of the code, but making such relationships explicit runs counter to the open-source nature of the project.
I would suggest, if you're concerned about whether certain parts of the code are "ready" for release, that the real question to ask is whether a coverage tool (such as JCoverage), combined with existing test cases, reveal a level of testing coverage that is acceptable for a release.
-Eric Johnson.
Let's consider an example: I certainly have no real idea of the guts of Peter's code and he hardly has of mine. That's fine as we both have our stuff to concentrate on. Now, when there is a bug in Peter's code I turn to Peter and ask him to fix it, maybe with a suggestion how it might work. All of this happens in the lists...
So, Peter is in charge of this specific piece of code. It is important to see who has written or at least who knows every specific part of the code. If there is no one identifiable and it is essential, we need to share responsibility, as suggested with the kernel packages listed below. Given the complexity of the code, if there was not at least one person in charge of every specific part of a release how could we dare make a release?
Also judging from my experience with this project in the past this policy has worked very well. It might seem too conservative, but many people rely on the code to work reliably. So, let the experts make the changes.
Having said this, Robert, can you please clarify your position?
Concerning Stefano's position that is much clearer to me, I strongly disagree.
But still, this is my *personal* view of all this. If views of committers diverge, let us have a vote. Shall we?
Thanks, Oliver
robert burrell donkin wrote:
+1
one4all + all4one :)
IMHO it's healthier to discuss any changes that you feel might step on others toes or that are controversial on the list before you make them. this gives not only the other committers a chance to join in but also the development community hanging around on the list.
- robert
On 18 Nov 2003, at 17:10, 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.
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.
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
