On Sat, 29 Jul 2006 10:27:34 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> said:
> [ text reordered during quoting ] > On Fri, Jul 28, 2006 at 11:10:24PM -0500, Manoj Srivastava wrote: >> > I agree. We should do it like the BSDs: a tree that any >> > developer can commit to, for any package. >> >> How would you handle dilution of responsibility? >> >> When everyone is responsible for something, no one is responsible. > I heard this argument several time. But as a matter of fact the > collaborative projects I'm involved with (pkg-ocaml-maint, pkg-vim) > do work well. Goon for you. My experiences differ. > Do you have examples of collaborative maintenance projects where the > "no one is responsible" part plays a role, making people willing to > go back to non-collaborative maintenance? Yes, there was a mention of it just this month on #debian-devel. I am unwilling to derail this thread with the merits of the maintainer and package team's position in this instance by naming names and bringing the affair into the limelight, but I can send you excerpts of the log privately. >> Or too many people making broad commits to to many packages without >> considering the details of the particular package being touched? > This happen in all large development projects and it is not a big > deal. Breakages do occur and people fix them. Is this all that > difference than a maintainer uploading a library breaking ABI > compatibility with tons of packages not touched by the upload? It could go either way, of course, but I was referring to the difference between due diligence of a group, as opposed to an individual; potentially, a team is only as strong as the weakest link. So in some cases the quality of uploads may actually fall, or impose greater burdens on the members inclined towards higher quality. On the other hand, the team may haul up a slacker lone developer to higher standards. The point is, no one can say ffffor sure a priori which road shall be taken. manoj -- Others may not understand that we must practice self-control, but quarrelling dies away in those who understand this fact. 6 Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]