On Wed, 17 Sep 2003, Greg Stein wrote:
> On Wed, Sep 17, 2003 at 11:26:45PM +0100, robert burrell donkin wrote: > >... > > anyway, rather than go over all the old arguments again, i'd say that it'd > > be better to go forward by looking at the positives that apache commons > > can offer (rather than getting into an argument about the jakarta mission > > scope). > > Well, to be honest, that is kind of a weird question to me. "what do you > have to offer?" Euh... project space? > > I mean really. The ASF is the same across the board. I don't see that > there needs to be a one-up-man-ship here. "ooh! we have X and they don't!" > > That may not be what you meant, but when I read "what do you have to > offer", that is how I translate it. It is kind of what I meant, but not the spirit. In effect it's much like having 'jakarta-oro and jakarta-regexp' to the average java user. They just sit there and go...."huh?" and want someone to tell them which to choose. We (the users) have to somehow be able to make a decision. So there's a project foetus that is written in Java, about databases and is reusable code. Because there is no dictatorial demands coming down from on high [for reasons of cat-herding I would presume?], I'm trying to figure out what the rules are I should apply to my basic set. For example: 1) Is your project a child of an existing Jakarta project [see jelly]? Or a plan for adoption [see hivemind]. If yes: Jakarta Commons. If no: Continue. 2) Is your project a child of a DB project [some component of OJB]? If yes: DB Commons. If no: Continue. 3) Apache Commons. Except...Xml Commons should be in there too. Also, Jelly is a child of Maven, and yet Maven is no longer a Jakarta project. What other options of input are there? Community seems a big one. Do I think that a project in Xxx Commons will gain more from the community. Unless I'm scared of the number of people in the community, the established Commons' [Jakarta, maybe XML] will be the choice there. I might want to choose Apache Commons because it currently feels quite httpd commons and therefore might have a high knowledge/fraternity for non-Java code. > Personally, I see Commons provide a community for building reusable > components. Matches the other Commons' I think. > Those components are independent, rather than beholden to some > larger project. In charter, Jakarta Commons disagrees here. In reality it is the same. Dunno for Xml and Db. > Of course, there *does* need to be recognition and respect > for your users, so versioning and API stability is very important. No different than other Commons'. > But Commons *is* a separate TLP which sets its own goals. Ooo. A worthy advantage, Apache Commons is at a higher level in the ASF realm :) > The Commons Project also has a bit of self-definition to complete, too. Yep. It's a large part of why I'm asking the questions. > One of the outstanding questions is partitioning of commit rights. At the > moment, I'm in favor of zero partitioning within TLPs. If you're a Commons > committer, then you have rights on all components. Social norms and > recognizing your knowledge/strenghts/weaknesses should keep people from > breaking components outside of their typical areas of work. Shouldn't be any problems with this. Apart from the usual language wars, but we all know the rules for that kind of thing [obey the project standard, obey the style of the original code etc]. > But from a > responsibility standpoint, it is expected that all Commons committers > would become part of the PMC, and that PMC is responsible for everything. > Partitioning just monkeys all of that up. Yep. This is a real plus of Apache Commons being a TLP. It is able to have a functioning PMC and not just a loud corner. > There is also a question of whether to have a sandbox. Do we allow people > to run with a good idea? To start it from scratch? If we allow "from > scratch" components here, then do we impose a minimum number of committers > "signing up" to work on it? (i.e. no one-man component starts) Tricky. A lot of code begins as one-man components, so do we just stick our fingers in our ears and ignore it until it becomes two-men components, ignoring the loss of cvs history, comments, and backup ability. Plus it makes it harder for the one-man to share. > Oh, and the part of me that prefers unification rather than replication > wants to ask, "so Apache Commons will be here in five years. how about the > other foo-commons projects?" :-) hehehe... With one project a year being added, I think the other foo-commons projects will have to still exist ;) Hen
