Answer inline: > -----Original Message----- > From: Scott Sanders [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 01, 2002 10:15 PM > > > -----Original Message----- > > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > > Sent: Friday, February 01, 2002 1:04 PM > > > > ... > > And that's the problem that I think peter is pointing out - > > that people can have binding votes on projects that they have > > nothing to do with... > > Peter probably has nothing to do with some of the server components in > Avalon, but he has a binding vote for them. How is that resolved? That > is the same problem.
Life in Avalon is quite different and much less problematic. The framework focus seems to enforce a more homogeneous culture and consensus is easier. (Although there is still a lot of room for discussion and competing solutions.) Avalon is not better or worse but it is a very different thing, with a different nature from the Commons. The commons looser structure asks for different solutions, although I am not sure which those are. > > One of the motivations for commons was a place for small*, > > discrete components to be able to be packaged and presented > > for reuse by both Jakarta projects and developers at large. > > Yes Which makes quite some difference from the Avalon style. > > ... > > > I don't think there is *any* downside to that model, as > > people who are committed and interested and want a role in a > > component will get involved in what I understand the > > traditional Apache/Jakarta way is... > > There is not a downside to that model, IMHO. That would have worked > fine as well. But I do think that Commons has an advantage with the > sandbox and the diverse group of committers. I started here because of > my interest in CJAN, and then Digester. Now I have great interest in > 'lower-level' components like io, codec, and util. I see no problem in > the current model of just 'jumping over' to do this. The sandbox is an important point. Maybe everybody should have access to the sandbox and maybe we should be really selective about what gets out from the sandbox. Maybe many components should just stay there much longer than others because some things take much longer to mature. However, some projects really need some stability because many others might depend on them, and me thinks that such stability is better served by a stable committer base. A lot of people say that the commons logging package is not really necessary but I bet that a lot of projects will depend on it soon. What if a committer changes it to suite some specific need without knowing well the package, its story and the other users/uses of the package? I am not sure that committing rules should be as strict as with projects like Velocity, but at least some principles should be laid down. And I sure can understand Peter's concern. A lot of other Avalon code depends on the components that could be moved from Avalon to the commons... and many other projects depend on Avalon. What if someone just breaks one of those components? I have no smart-ass answer for this problem but probably the answer is not full bazaar mode, as it probably is not full cathedral mode. > ... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
