I do not think that a "official" assignment is needed. Responsibilities will evolve or are allready there (implicit). Other os projects work as Oliver describes. But without assignment.
Martin Oliver Zeigermann wrote: > I really wonder if we have a misunderstanding here. > > 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]
