> -----Original Message----- > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 01, 2002 1:49 PM > To: Jakarta Commons Developers List > Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release > > > On 2/1/02 4:15 PM, "Scott Sanders" <[EMAIL PROTECTED]> wrote: > > >> -----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. > > I don't know enough about Avalon and Peter's role. Doesn't > seem to be the same problem if they are making a coherent > server framework. > > We aren't, right?
Not a framework, but hopefully a cohesive set of independent reusable components. Creating a generic component is as much of a singular mindset as creating an entire framework. > > > > >> > >> 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? > > Because they are very small and then Jakarta would become > more confusing to the outside world than it already is. I think that has already happened IMHO. Why stop now? JK, I think that we could help in this area, somehow, someway ;-) > > > > > I believe the group dynamic of many committers, some not > knowing the > > code of certain projects, serves to try and KEEP the components > > generic. > > The community dynamic wouldn't change. Anyone interested > would almost for certain be able to become a committer in > anything they chose... I can agree with this, yet for some reason I still resist :) > > >> > >> 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'? > > Too many of them. Hard to manage, hard to present... Already there, IMHO. At least if we added hundreds more, the problem would *HAVE* to be solved. > > >> > >> 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. > > Both of which you would get with the common model - everyone > has rights in the sandbox (it's one singular CVS) and they > are still as diverse a community as they are now. OK. It's whole agree, but disagree thing. I agree with you, but I also think that some sort of commit status deprecation needs to take place, in order to truly make this type of community work. > > > 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. > > Right, and IIRC, you made contributions to Digester gradually > with increasing confidence over time on both your part as > well as the rest of the committers to Digester. Yeah, but just because I was afraid of Craig ;-) > > So if it was the conventional model, you would have submitted > patches, and then someone would say "Hey, we're sick of > applying yuour patches - want to be a committer?" Or > something like that. Yes. But, the same problem exists in reverse. I am a committer to Digester, and two years later, after no activity, I veto a release because it uses SAX3, and I don't like David Brownell. This is all part of a 'larger' problem. > > > > > 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. > > Except if you do not participate, then you don't have a > *clue* what their intent and hopes re Javadoc are, so you > might not be doing them any favors... Maybe. > > And by jumping in like that, you possibly take away one of > the 'activators' of the community model, non-committer > posting patches repeatedly, demonstrating interest, so the > 'regular' committers to the project notice, evaluate, and > then offer committer status to the poster. If you jump in, > the regular committers might not then interact or notice the > contribs from the non-committer. Or maybe I see Paulo contributing in several areas, and convince the rest of us to make him a committer :) Scott > > > > >> > >> geir > >> > >> > >> (*) I have no idea what 'small' really means :) > > > > Understood. I thought Tomcat was 'small' ;-0 > > Right - I just didn't want it to appear to be a negative attibute ... > > -- > Geir Magnusson Jr. > [EMAIL PROTECTED] > System and Software Consulting > POC lives! > > > -- > 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]>
