On Wed, Oct 23, 2002 at 05:05:19PM -0700, Scott Sanders wrote: > On Wed, Oct 23, 2002 at 04:34:17PM -0700, Greg Stein wrote: >... > > Hang on here. Are you suggesting that when the *BOARD* chose to call this > > Apache Commons, that the Board somehow "stole" the name from one of the > > things that the ASF already owns? How is that possible? > > I think that what is being stated is not that the board 'stole' the name, > but that if it actually comes to pass in the future that the board decides > to merge the two communities, as you explain later in this message, the > jakarta-commons group will NOT have a choice in the matter, and the rules in > the new group will be very different from the old group.
To be honest, I don't have a lot of sympathy with that POV. For two reasons: 1) Existing J-C committers can participate here, too, and help to shape the final charter of the Apache Commons. We can't read minds, after all :-) 2) Any rules that the Apache Commons defines will be with an eye towards the benefit of the ASF. Two of the Commons PMC members are founders of the Apache Group (the predecessor to the ASF); three PMC members are on the Board of Directors (three being a third of each group); and one is the Chairman of the ASF. I seriously doubt that we will end up with something that is harmful. Different from what the Jakarta Commons people are used to? Sure. But this item isn't trying to be backed on authority, but on *history* and experience. Jim and (especially) Ken are practically the embodiment of the rules and behaviors behind what has built the ASF. And part of that is listening. If you look at the above two items, it comes down to: participate on this list if you want to see things work a certain way. If you don't participate, then you better not whine about the results. And it *does* seem like we're getting input from the J-C committers (Morgan, yourself, etc). I worry more about the XML Commons people; but then again, maybe there isn't an active enough community to be much bothered either way. For example, I've been thinking of committer restrictions per component, while J-C has committers as a whole. I (still) disagree with that approach, but after the emails here, I now understand it and can see some of its benefits. Short answer being, "is there a synthesis we can achieve on commit privs? [and the resulting voting rights]" >... > > *IF* the overall ASF and/or Jakarta restructuring occur, and some kind of > > flattening takes place, then I can almost positively state that there would > > not be two top-level Commons projects (I really could not see a case where > > the Board would want to have a language-agnostic commons *and* a > > Java-specific commons). More precisely, I would vote to combine them in that > > case; what the Board majority chooses... dunno, as I'm not speaking for > > the other Directors and their voting choices, but I'm pretty sure it would > > be combination. > > This is the point, I think. If the restructuring does occur, and there > cannot be two top-level projects named commons, then it could be perceived > that the board 'stole' the name :) Nah. If it happens, then the answer is that they "moved" it :-) Seriously, I kind of fail to see the distinction. The Apache Jakarta Project came up with a neat idea for reusable components and called it Commons. That concept is part of the ASF, so how could it be stolen? My impression is that the perception of "stolen" exists only if the people involved with J-C see it as their own concept, rather than part of a structure that they helped to create as part of the ASF. IMO, if the mental model was more tightly associated with the ASF, then expanding the scope to include more ASF committers would be seen positively (and dropping the Jakarta prefix would be a natural part of the change in scope). > So, if this is to be the eventual case (possibly), then why not start the > whole thing with an existing community, Nothing is excluding the existing community. I personally encourage the entire Jakarta Commons communtity to participate here. > with an existing set of rules Why shouldn't they be reviewed? I'm not sure they can be taken as gospel, and given some of the statements about obstructionist vetoes occurring under those rules, then I'm quite sure they ought to be reviewed. But *nothing* says they should not be considered. Why not bring them up as we discuss different points? Seems like that is already happening. > and projects, And again, all the projects are highly encourage to migrate. Nothing is saying they are not welcome, and nothing is holding them within Jakarta. > and just add language-agnostic to the charter? Because the scope is expanding and Jakarta's scope is already too large. Jakarta is already busting at the seams of the charter specified by the Board, and expanding the Jakarta Commons subproject will do nothing to help that. The Board creates Projects as mechanisms to provide oversight of the code that is developed by and for the ASF. Recognizing Commons as a Project in its own right is a good thing. > > To that extent, I believe it is important for people with experience in how > > Jakarta Commons operates to bring that to this forum. To help the Apache > > Commons project set up a structure that allows for participation for > > different languages and different types of components. Commons is still > > refining their detailed charter (beyond the more general one specified by > > the Board) and their procedures. > > I also agree jakarta commoners should be involved. Some people just > believe that jakarta-commons should have been used as the prototype. It is, provided that the info and experience is brought here. If you provide all of the same ideas, concepts, and experience here, then that is the same as using J-C as a prototype. I think rather than saying "used as the prototype", the phrase you may have been seeking is "expanded to incorporate the new scope." But as I mentioned above, the Board didn't really see expansion as a valid approach given its larger role at the ASF, and Jakarta's existing charter/scope. Cheers, -g -- Greg Stein, http://www.lyra.org/
