On 2/1/02 4:00 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> Paulo Gaspar wrote: >> So, I agree with Peter: the commons will get too big and has a >> too loose structure to control things like this (which is still >> not the case with Avalon). >> >> I am not sure about how strictly one should regulate that, but >> maybe it is necessary. > > I think the only recourse then is to propose the Commons as a top-level > ASF project. > That's the *only* recourse? Why not just use conventional voting rules : if a person wants to work on a component, they get committer status in the regular, tried and tested way...? > > As it stands, in a Jakarta subproject a Committer is a Committer, and I > don't know if we want to get away from that. Why not? State a reason. > Many other people think that a Jakarta Committer should be a Jakarta > Committer, so if Velocity broke Turbine, then Turbine could veto the > change. No thanks. That would mean that I could lead another project off a cliff with creative uses of their released code, vetoing them fixing the side effects, and forcing them to keep me happy. > But I think few people would want to move in the other direction, where > you had to be voted into each package for a subproject. Why not? We just did that in Velocity with the new -tools subproject, which gives people with that specific interest and expertise a chance to participate and contribute. Seems to be a plus to me... Doesn't avalon also compartmentalize the project? geir -- 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
