> -----Original Message----- > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 01, 2002 1:04 PM > To: Jakarta Commons Developers List > Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release > > > On 2/1/02 3:43 PM, "Scott Sanders" <[EMAIL PROTECTED]> wrote: > > > How do you enforce this? How do you handle this in the > Avalon world? > > I consider (only just recently, BTW), that a committer in > Commons is a > > committer to the entire commons codebase, including the sandbox. > > 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. > > 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 > > So to me, it was to be a container for 'mini-projects', each > behaving like any of the other top level projects in jakarta: > Each had a user community, each had documentation (hopefully > like the other components :), and each had committers that > were committers because they showed interest, dedication and > provided value. Now, that the user communities overlapped, > and that the developers overlapped didn't matter - in fact, > that made the whole model stronger because it coupled what > appeared to be islands together into a more cohesive group. > Further, the sandbox was added to offer a completely open > place for anyone to play, test, experiment and most > importantly, collaborate. Container for mini projects: Yes. Behaving like other top-level projects: No. If this was the case, why wouldn't they just be top-level projects? I believe the group dynamic of many committers, some not knowing the code of certain projects, serves to try and KEEP the components generic. > > However, that's not how it finally turned out. > > I too believed then and still believe now that we would be > better served with the conventional Apache/Jakarta committer > model in Commons, where each component is a well defined > group of interested people, a part of the larger community as > well, of course. But, then again, why not just create top-level projects whose clear goal is to do 'x'? > > 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. I am not blocking progress of Latka or httpclient. I do not participate over there, but I might in the future. I would definetly be willing to look at a patch for something as simple as JavaDoc. That's where I think the strength of the Commons is. > > geir > > > (*) I have no idea what 'small' really means :) Understood. I thought Tomcat was 'small' ;-0 Scott > > > > > Let a person's code speak. > > > > Scott > > > >> -----Original Message----- > >> From: Peter Donald [mailto:[EMAIL PROTECTED]] > >> Sent: Thursday, January 31, 2002 12:05 PM > >> To: Jakarta Commons Developers List > >> Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release > >> > >> > >> On Fri, 1 Feb 2002 05:06, Scott Sanders wrote: > >>> What needs to be changed Peter? > >> > >> People who dont contribute to a component dont get voting > rights over > >> a component. > >> > >>> Explicitly state it in a > >>> proposal/vote/patch and let's do it. > >> > >> I have proposed it several times before. If you go back to the > >> original vote for commons you will see that I only started > waving the > >> Avalon duplication > >> flag after I was ignored on this issue for the second time. I > >> had hoped Jon > >> would have picked up on it and we could have forced the > >> proposal to include > >> this requirement but it didn't happen this way. > >> > >> -- > >> Cheers, > >> > >> Pete > >> > >> --------------------------------------------------------------- > >> The difference between genius, and stupidity? Genius has limits > >> --------------------------------------------------------------- > >> > >> > >> -- > >> To unsubscribe, e-mail: > >> <mailto:commons-dev-> [EMAIL PROTECTED]> > >> For > >> additional commands, > >> e-mail: <mailto:[EMAIL PROTECTED]> > >> > >> > > > > -- > > To unsubscribe, e-mail: > <mailto:commons-dev-> [EMAIL PROTECTED]> > > For > additional commands, > e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > Geir Magnusson Jr. > [EMAIL PROTECTED] > System and Software Consulting > Be a giant. Take giant steps. Do giant things... > > > -- > To unsubscribe, e-mail: > <mailto:commons-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
