> -----Original Message----- > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 01, 2002 2:17 PM > To: Jakarta Commons Developers List > Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release > > > On 2/1/02 4:54 PM, "Scott Sanders" <[EMAIL PROTECTED]> wrote: > > >> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > >> > >> 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. > > > > Ok - describe what you mean by 'cohesive'? I don't > understand the phrase "cohesive set of reusable components".
By cohesive, I would hope to mean that if you've used one, you could easily use another with a minimal amount of trouble... > > >> > >> 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. > > To some degree, I 100% agree. > > > Why stop now? JK, I think that we could help in this area, > somehow, > > someway ;-) > > Are you serious about the "Why Stop?" The JK means Just Kidding :) > > >> > >>> > >>> 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 :) > > Yes - I understand that... > > >> > >>>> > >>>> 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. > > Yes, like maybe having a project that is a container for the > smaller components? > > ;) With another PMC and everything? :) How many levels of abstraction do we need to code? We need the ASF and the ASF Board to protect us from a corporate perspective, and then there should be the coders. That should be it. > > >> > >> 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. > > Deprecate what? Here's one approach : Committer status to inactive committers. > > 1) Freeze committer status as to what is in the STATUS > files, pre-Peter :) > > 2) If you are a committer in a component, you are a commons committer. > > 3) If you are a commons committer, your rights and > responsibilities include: > a) sandbox commit rights > b) The responsibility to vote on new components being added > to commons - I think the group dynamic is important in > shaping the overall 'flavor' of commons going forward. > > 4) You can be added as a sandbox committer independently of > commons, to let strangers in to start contributing > immediately either with new things, or collaborating fully on > things existing in sandbox. OK, but I do not see how this makes the situation better. > > > I don't think the above is in spirit or letter a radical > departure from what we have now. It just tightens up the > problem that we knew about and Peter effectively demonstrated. > I just don't agree that there is a problem... > > >> > >>> 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 ;-) > > We all are at some point. ;) > > And try starting out by committing to a project with Jon > Stevens as an active committer :) and do it by suggesting a > feature he is *dead-set* against. True test of ones > commitment to the idea, I will say... I started out in Jserv, and was too scared to ever make enough patches to be a committer, but I got over it... I really like jon a lot *because of* how he conducts himself. > > >> > >> 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. > > Nope - two years of no activity, and you aren't eligible to vote :) This is the case? This is good. What counts as activity? Do you have a URL? > > > > >> > >>> > >>> 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. > > Sure - I wasn't suggesting that you personally would be that > way - just that you can imagine that it's possible in general. As Costin said, anything is possible, but probable is a different thing. > > >> > >> 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 :) > > That's good too. But you would see that as it's still one big list :) Or would it be? > > > -- > Geir Magnusson Jr. > [EMAIL PROTECTED] > System and Software Consulting > "The J2EE Compatible brand has achieved significant momentum > over the past two years, and we want to make sure that any > open source efforts don't impact the viability of that effort. " > - Karen Tegan, Director of J2EE Compatibility and Platform > Services Sun Microsystems > > > -- > 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]>
