Re: [draft] SD Magazine: request for change
Danny Angus wrote: ... the issue is *only* that The Apache Jakarta Project and leading Tomcat contributor JBoss implys that JBOSS is not only a contributor, but *the* major contributor. Fact is that JBoss is _a_ major contributor to tomcat. So is any company that have committers working full time - in any project. ( in addition the architecture of tomcat5 is based on jboss jmx model, and that's _a_ major contribution as well ) Sun is also _a_ major contributor to tomcat. So is any other company that is funding tomcat developers. Code is written by people, but companies like JBoss or Sun are actually paying the bills. Of course, a lot of credit must go to people who manage to cut hours from their families and free time. Leading contributor does not imply the only contributor or the only leading contributor. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [draft] SD Magazine: request for change
Davanum Srinivas wrote: Rémy, You will probably need to resend the CCLA...i can't find in the regular location where ccla's are recorded. - Can u please explain what you mean by current attitude? It's already 'explained' in various mailing list archives, including this thread :-) - Are u saying that Tomcat is *NOT* really Apache Tomcat? I thought it's Jakarta Tomcat :-) I checked the web site - it says 'Apache Jakarta Tomcat' - but most of the docs and packages are jakarta-tomcat or just tomcat. There are quite a few books, articles and many sites out there using either 'tomcat' or 'jakarta tomcat' - should we ask for a change as well, or is it only for jboss ? - Are you saying that we need to formalize a mechanism to figure out which company is a leading contributor to a certain project? I would say each company and contributor is a 'leading contributor' :-), but it is true that some companies contribute more - Jboss and Sun in particular for tomcat ( at some point it was Sun and IBM ), and I think they deserve credit for spending money on this. Formally - each contributor has the same voting and veto rights in any project, and is free to 'lead' with his contributions. How people outside apache see the fact that few individuals contribute more is a different story. It happens in all projects - even httpd - that at some point 3-4 people are extremely active and contribute more than the average. Is it fair to say they 'drive the project' or are making 'leading contributions' ? That's the reality - may not be politically correct in apache culture ( we all know board/pmc/philosophy/oversight/abstract community are the 'leading contributors' in any project, not individuals :-) I've seen a lot of cases where people or companies have claimed a 'leading' role in various apache projects. This is the first time there is a rush to correct this. Is jboss a factor ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [draft] SD Magazine: request for change
It's never bad to clarify things. For example ( honestly ! ) it's the first time I hear that the name of the project is Apache Tomcat. Someone should send a mail to tomcat-dev to inform them, the tomcat site is under the impression that it's called Apache Jakarta Tomcat - and almost all docs and packages and books are 'jakarta-tomcat'. I'm +1 on your email if you are going to send the same kind of email for every use of Tomcat and if we are going to send an email every time a company or individual claims he is making 'lead contributions' to an apache project. And I would feel much better if such rules would be written down ( so we can point people to it - and use them in all cases). I'm -1 if this is only about Jboss, it's just not fair. If tomcat would be a top level project instead of jakarta-tomcat, most likely Remy would be the PMC chair. Acording to ASF rules, the PMC chair is the ultimate decision maker for a project. It seems the notion of 'project leads' is not accepted by some - yet the entire legal organisation of apache is based on a top-down hieararhy ( Board - PMC chair ). I don't know what is worse - the perception people have about things, or the reality. Costin Henri Yandell wrote: On Sun, 20 Mar 2005, Bill Barker wrote: - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: general@jakarta.apache.org Sent: Sunday, March 20, 2005 3:01 PM Subject: Re: [draft] SD Magazine: request for change Henri Yandell wrote: It may be that leading contributor is, while not an 'Apache Way' to discuss something, a completely true piece of investigative journalism. There are definitely parts of Commons where a little bit of investigation could point out that Yes, on DBUtils 1.0, David Graham was the lead developer (Sorry David :) ). That may be true, but certainly we do have the right and responsibility to ensure that our desires, as far as how we run and represent ourselves, is accurate as well. It has always been a major foundation of the ASF that projects are built and developed by communities, not individuals. Terms such as lead or main do cause harm to the community and have always been actively avoided. And, yet, all of the complaints about the article have been from people that aren't involved with Tomcat development ;-). Yeah I've noticed. So far we have Costin, Mladen, Remy and yourself all fairly nonplussed by it all. Nothing from Yoav yet. Unsure who else is highly active in Tomcat at the moment. Obvious quandry for me, we don't really have any concept of subcommunity, apart from the individual dev lists, it's supposed to be the Jakarta community at large and apart from Tim who feels that we should focus on the Tomcat and JBoss sites and not SD's release, that community is in favour. I'm trying to walk the line here :) I do think the 'leading' is wrong, and it's worth the ASF doing its best to sell its philosophy of community developed software. All the suggestions to soften my email are very well received, I was trying for informal but failed (I'm trained to only use small talk when holding a beer). However, unless the Tomcat developers want to -1 the email, the consensus is to send it out (with a few minor, suggested changes). A quick show of hands on tomcat-dev to the idea of sending a -1 to the general@ list might be simpler than sending various -1s and -0s to the list individually. I'll put back the estimated send-time until tomorrow night (28 hours from now basically). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta - A study in self defeating projects
Shapira, Yoav wrote: Hi, The folks at JPackage.org already track several Jakarta projects and issue RPMs for them: for example, they've been doing this with Tomcat for a long time. We appreciate their work. We've spoken on the tomcat-dev list about issuing our own RPMs, and I think it was Costin (Manolache) who was very interested and knowledgable in this area, so he might be a good person to ask if you're interested in more Jakarta/RPM work. I'm just very unhappy with the current status and how linux distributors are packaging java projects ( tomcat in particular ). The problem is that each distributor ( RedHat/Fedora in particular ) are using a layout different from each other, making it harder to support. On top of this - Fedora is using native compilation, a great technology but not very stable yet. On tomcat - the conclusion was that we could distribute our own rpms, if we can make it easy to build them and integrate this in the normal build ( and a special requirement - have this working on windows too ). I didn't have time to implement this yet. One problem with RPM is that it is both a packaging/install tool ( like InstallShield or tar.gz ) but it is also at the same time a build tool, like make or ant. And you need special setup to build RPMs using the rpm spec on Windows, Mac or Debian computers (it is possible, but not very simple out of box ). As a solution - I started on an Ant rpm task that would just create the rpm file from the distribution files, without using a .spec and all the special steps ( just like the windows installer does ). JPackage.org is a great source for java packages - and at least they are self-consistent and work on any linux (RPM-based) distribution. But just like the other distributors, their layout is different from the official distribution layout. While I don't like linux distributors and the fragmentation they create, I think it's also our fault for not distributing official RPM files, to keep the products consistent both across various linux distros but also across platforms. Costin I know the above is off-topic for this thread, but since the thread is dying anyways (the OP was a classic I'll send a clueless rant and disappear type), and this is relevant (and of increasing concern as various linux flavors gain popularity not just in our community, but on our users' desktops). Yoav -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Monday, October 11, 2004 10:42 AM To: Jakarta General List Subject: RE: Jakarta - A study in self defeating projects Henri Gomez wrote: If some people found hard to install and glue jakarta software (not products) together they should consider JPackage.org ready to use RPMS. This Linux project make a cross distribution coherent Java distribution, which is now used by Mandrake, Suse and Redhat. If you can think of some way of validating the contents of the RPMs (e.g., if they were part of the release testing process and signed by an ASF release manager), maybe we could do something with jpackage.org. Or add the RPMs to our dist/ tree. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache should join the open source java discussion
Noel J. Bergman wrote: What about starting by making sure Apache java projects _do_ work with the 2 open source JVMs that are mentioned in the article ? Which two? I've had a thought to try testing James under gcj at some point. RedHat has already done a whole bunch of Java-based Apache projects with gcj. Well, if you read the article that started the thread... You won't like it... The other open source java virtual machine is ... Mono. I think supporting GCJ and maybe kaffe would be good enough to start. And regarding Danny's comment - yes, testing and reporting bugs is the best solution, but just like we worked around bugs in Sun's VM, we should also try to work around bugs in the open source VMs, at least until the bugs are fixed ( or even better - until patches we send get included into the JVM CVS ! :-). At the moment Classpath project provides an almost complete implemnetation of the JDK1.3 ( with a lot of JDK1.4 ). And the same implementation is shared by all open source VMs that I know. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] HiveMind as a Jakarta sub-project
Geir Magnusson Jr wrote: [X] +1 I support this proposal [ ] -1 I don't support this proposal [ ] 0 I abstain from voting for or against this proposal Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extending the PMC ( was: Re: [PROPOSAL] Proactively encourage TLP status)
Ted Husted wrote: Right now, the only plan seems to be to nominate committers one-by-one on the PMC list. I'm just saying that we shouldn't play favorites. I believe all Jakarta committers have already earned membership in the PMC; we should tender the offer to every Jakarta committer and let each decision-maker decide for himself or herself. If the consensus is that the bootstrap PMC will continue to hand-pick which of our duly-elected committers are promoted to the PMC, and which are not, then so be it. But, personally, I think that process is nothing but busy work. The community has already decided. Let's ratify the community's decisions and let Jakarta be whatever Jakarta wants to be. +1 It seems this is the consensus, to add most committers - one by one or ten by ten. Let's go with that for now, almost everyone is agreeing with the goal of having everyone who cares included ( I didn't see a vote yet, but it seems pretty clear we agree on this ). I don't like the process of hand-picking either - unfortunatly that's the norm in ASF ( membership and all other PMCs use the same mechanism). I hope after we get past the first stage we can have a [VOTE] and change this to people _volunteering_ for PMC - by sending a mail with subscribe subject and the list of sub-projects the person is volunteering to monitor. IMO the only way out of this discussion is to divide the problem into very small pieces and have real VOTEs and counting of each of them. Proposals with more than 1 atom have no chance, and most of the problems occur because everyone seems to think he knows what the others think without asking. Please people, write down what you want, separate it in very elementary pieces, then post a VOTE and see what the majority things ( it may be consensus or a simple majority - but at least you'll know what other think ). Like: 1. Extend the PMC: - to include all committers ( even if the don't want ) - to include all the comitters who want - to include all who want and prove they understand the rules 2. Future extension of the PMC: - hand-picking by current people - people volunteering - because we trust them already to write the code and do the work, and it's fair to let them join whenver they want. 3. Jakarta and TLPs - 'encourage' every subproject to TLP - let each subproject decide if they want to leave jakarta- without encouragements - 'encourage' only subprojects that have problems - do a selection based on some characteristic ( like projects that fit togheter - whatever that means) - try to keep jakarta togheter and increase the community ( as jakarta-commons did ). If someone really wants to go - of course let him. 4. Is jakarta a good thing ? - yes, not perfect but we are improving and working better with other jakarta people - no, it's just a mess - yes, other projects should do what jakarta does ! I hate when people keep talking about consensus and argue as if they knew what the consensus was, but we don't have even the most elementary vote to indicate what a majority thinks. And BTW - please make sure that the votes explicitely state that all _committers_ should vote, but only PMC member votes are binding !!! That's why people should volunteer for PMC, however this is about jakarta and comitters are what jakarata means. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
Stephen Colebourne wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] What really saddens me is the idea of chasing them out the door. To use an analogy, its like being the parents of a family, where the children, aged from 4 to 40, are all living at home. It strikes me that it isn't healthy for that 40 year old to be living at home, expecting his parents to do the washing, feed him and make his bed. Instead, the good parent should be gently enabling the child to set out on their own in the next phase of their life. Sometimes letting go is the hardest part of being a parent. Stephen So you consider jakarta subprojects as some children, the PMC that makes the bed and feeds them ? ( and the board as the big brother I suppose:-)? I don't know where did you get this idea, but it seems there are quite a few people who feel like big brothers who know what's better for the childish jakarta projects and would like to encourage them to do what they think is best. I see jakarta more like a union ( EU-style ), were the different projects that joined are mature entities that choose to be part of jakarta ( and can choose to get out - all that's needed is a vote ). And the PMC role is to make sure the rules are respected ( oversight ) - not to wash/feed/make the bed for subprojects. So I'm -1 on your proposal ( if you care counting - it seems most people who propose pushing projects to TLP would do anything to reach this goal - except proposing this in the sub-projects they participate in and counting the resulting votes ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
I think I missed the VOTE thread where this proposal has been approved. So far I've seen 2 +1 and 2 -1 votes ( including mine ), this doesn't seem like a consensus. It's better to wait for the vote to finish ( and it would be nice to have a [VOTE] thread and a time limit ) before starting to do it. Ted, Stephen - you are free to propose or encourage any subproject to do whatever you want - but please make clear that this is your personal opinion or proposal ( unless jakarta PMC or the board votes on this ). But please start with the projects you are dirrectly involved with :-) - I don't think it's a good practice to act as a parent for childs you don't know very well. Costin Geir Magnusson Jr. wrote: On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Ted, I think we must focus on what we agree on - it seems nobody is against expanding the PMC to include most committers ( or all active committers who don't decline ). I'm not sure I understand Geir's current position, but I think he still agrees we need to include most people. I don't think anyone can argue for excluding some active committers - I'm ok with a wait period ( i.e people who have been active committers for at least N months ), but it has to be a deterministic process. In addition to that, there are other things we need to do - like making sure we have clearly identified people who will prepare the reports for each codebase ( be it moderators, release managers, rotation, drafts or whatever a project wants to do - as long as the result is 2-3 names and a monthly report ). We also need to clearly identify what the board means by oversight ( to be honest - I don't know, I just have a vague idea, haven't seen any official definition :-). Since this oversight is motivated by legal concerns - I think we need a definition understandable by everyone, not just guesses. But doing it all at once is very unlikely to work - with all the strong opinions around jakarta. Divide and conquer - first step is to grow the PMC - IMO you need to simplify your PROPOSAL to make it focused to one point ( instead of solving more problems at once ), and move to VOTE. Costin Ted Husted wrote: I apologize for not quoting. I'm experiencing technical difficulties and making do the best I can. I meant what I said. We must make an immediate, good faith effort to correct the false and misleading information in the Jakarta guidelines, and give all committers due notice of their true status. Otherwise, there's a point where we cross the line. The PMC does not now nor has it ever affirmed each and every decision made by the committers. It may affirm some of the release votes, but there's a lot that goes into making a release. And, AFAIK, the PMC is not authorized to delegate its decision making to non-members. IMHO, we all thought we had the rights and responsibilities of PMC members in the first place. When each and every of these committers were appointed by a subproject, they had the traditional role of a PMC member in mind. Hence, the proposal is to make all Jakarta committers PMC members, which, I believe, was the underlying intent of the original guidelines, and what we all thought was happening in the first place. I reject the idea that being a PMC member brings additional responsibility. All committers are already responsible for decision-making and oversight. We simply need a mechanism that reminds everyone of our existing responsibilities. If all committers are subscribed to the PMC list, and each subproject is given the explicit responsibility for regular reporting, I sincerely believe we will be able to easily dispatch the oversight issues. All we need is a little infrastructure, and the volunteers will take care of the rest. A long-standing principle at Jakarta has always been that the highest, best votes are the commits. We have always rejected the idea of committers without binding votes. To say now that votes are socially binding but not legally binding is inconsistent with community standards. I am happy that we do have communities that will honor the votes of all its committers, whether they are legally binding or not. But, our legalities should reflect the community standards, which are that a committer is a committer. Obviously, if a committer wants to opt-out and become a developer again, that is their choice. But we should not be second-guessing the communities by opting-in committers to the PMC. The community thought they were good enough to have binding votes and binding vetos: who are we to say different? I've proposed my solution: Promote everyone who doesn't opt-out to the PMC; subscribe all committers to the PMC list; require regular reports from each subproject. AFAIK, the only other option on the table is to continue to nominate committers willy-nilly and hope-against-hope that a few more heartbeats will somehow give the PMC the wisdom to make decisions on the subproject's behalf and the mystic ability to oversee all the codebases. I don't think we need to create a Jakarta elite. I think we need to do what we meant to do in the first place: let the committers make the binding decisions. Accordingly, if a positive consensus develops among the committers regarding the original proposal, we can bring it as a vote in the Jakarta way. Otherwise, I would just let the proposal drop, so that the consensus view can proceed. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Ted Husted wrote: steward The proposal is to expand the role of the moderator, rather than invent an overlapping role with similar responsibilities. If the volunteer is not up to task, then another volunteer can be sought. (Hence, the language about the Chair appointing another volunteer.) The idea is that they have *already* volunteered to moderate the list. If one individual doesn't want to volunteer, another can be found. They volunteer to moderate a mailing list, not send reports or be a sub-commitee secretary ( if sub-commitee would be allowed - which AFAIK is not ) :-) My point was that there is no need for another role or hierarchy. Would we start organizing elections for mailing list moderator ? delegate The proposal does not delegate the board's responsibility. To be binding, anything voted on any DEV list would still need the a 3+ quorum of PMC members. PMC members would be voting on PMC business. There is nothing anywhere that says all the PMC business has to take place on a single list. If PMC members want to subscribe to all the lists and monitor all the PMC business, that's their choice. Conversely, if PMC members want to abstain from the routine business surrounding a given codebase, they don't have to subscribe to that DEV list. I agree with that. But keep in mind that any PMC member can subscribe to any jakarta mailing list he wants and vote or -1 if he sees a problem ! I still think that important votes should take place on jakarta pmc list - this will keep the entire PMC in the loop. Meanwhile, through the steward's reports, the committee-at-large is being kept in the loop as to each subproject's big picture. The proposal does the things. What about changing from mail list moderator to the current release manager(s) ? Each codebase already has one ( or few ) release managers, and they are already responsible for announcing releases and important events. * It realizes the fact that Jakarta doesn't have non-binding committers (meaning that all committers must become PMC members). May. It is not mandatory. * It provides a clear mechanism for scoping the work of the PMC. The business of each subproject can be conducted by people who are in-touch with that subproject on that subproject's DEV list. +1 ( but votes should still be on [EMAIL PROTECTED] ) * It provides a clear channel for oversight. +1 The steward's reports are designed to ensure that someone is at least thinking about these matters on a regular basis. Since it's someone's role to report on these things, they are more likely to be reported. Some issues we had in the past would not be readily addressed, since all the committers will be on the PMC list. A PMC member won't have to go off and talk to a subproject and report back. The subproject committers can hash issues out on the PMC list, where other members can provide input. And, any committer/PMC-member who thought there *might* be a problem, can now bring it up directly on the PMC list, whether the steward brings it up or not. Well, a PMC member won't talk to a subproject - it may talk with fellow PMC members if he is not tracking that project. Anyway - I think it's a good idea to have someone send reports, I just think that the release managers are a better choice. They are already responsible for making the proposal and vote for the release. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Andrew C. Oliver wrote: Radical view: allow the subprojects to send 1-2 delegates to the PMC and require each subproject to send one or die. This would size the PMC, assure that heart attack in the crowd syndrome doesn't take place and make the discussion more manageable. Have the sub projects manage their own policy for who to send and for how long under threat of being closed. This also prevents PMC for life syndrome and makes sure that the PMC serves not only the boards interests but the committers of the projects. It also puts pressure on PMC members to keep discussions public. I don't like this 1-2 delegates. All active committers in a subproject should be in the PMC ( unless they don't want to ). The concern that there are too many people is absurd. What is missing is a bit of discipline in proposals/votes - and that has nothing to do with the number of people. As you said, all discussions should happen on jakarta-general - so each jakarta committer ( including those who chose not to be in PMC ) get to participate and express their opinion. The vote should be on jakarta-general too ( counting as binding only PMC member votes, of course ). The difference between committers who are in PMC and the other should be only in the counting of the votes. The other argument - that nobody can or want to be responsible for codebases he is not involved with - is also bad. Each PMC member is overseeing whatever he chooses to ( typically the projects he is involved with and some he voluunteers to ). Every member of the PMC can vote on any issue - but it is common sense that those who are not involved with a codebase will abstain ( unless they have a good reason not to ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Ted Husted wrote: Michael Davey wrote: Jakarta is the *brand*. It defines itself. Jakarta brand development. A brand can give a unique identity and grouping to an otherwise disparate and commodity range of goods and services. Apache is a brand too, and, IMHO, a much stronger brand than Jakarta. I believe Jakarta distracts people from the fact that everything we do here is on behalf of the Apache Software Foundation. We are not Jakarta Committers, we are Apache Committers. We use the Apache License, package our product for apache.org, check code into cvs.apache.org, and donate every line to the Apache Software Foundation. We are apache committers - but each apache committer is also httpd committer or cocoon committer or jakarta comitter. You can't deny that HTTPD has a community of people, just like jakarta - which is not identical with the whole ASF ( even if ASF was originally the HTTPD community ). ASF is a collection of communities - some bigger, some smaller. Jakarta happens to be the bigger - and as long as you believe we are jakarta committers, you should also accept that jakarta _is_ a community just like httpd. A lot of people seem to have a problem with us feeling part of jakarta - and at the same time denying that jakarta is a community. IMO TLP is very closely related to community - in the sense that each TLP is or should be centered around a community. I realize that there are people who have romantic notions about Jakarta and like to talk about preserving Jakarta for Jakarta's sake. But for the life of me, I can't see why. For me, it's always been about the codebase and its community. If a product I use is hosted at SourceForge, I work at SourceForge. If it's hosted at Jakarta, I work at Jakarta. If it's a top-level ASF project, then I work there. I go where my community lives; and my community is centered on a codebase, not a hostname. I think it's not about codebase or hostname, but it is about community. As long as a project choose to remain part of jakarta - and refer to themself as jakarta committer - they are part of the jakarta community, just like an HTTPD committer is part of the httpd community. And a community with people from struts + tomcat + velocity + taglibs + cactus + POI + ( whatever projects choose to remain part of jakarta ) is IMO stronger that N separate TLPs, sourceforge-style. There are people who have called Jakarta a jewel. I'd agree that Cactus is a jewel, as is Lucene, and Velocity, and all the other *communities* we've built around our codebases. But Jakarta is not the jewel, at best it's a jewelry box. The fact that people from velocity, struts, poi, etc are all involved in this discussion about jakarta should mean that jakarta is a bit more than a sourceforge. All along, there have been people who envisioned a Jakarta community. But, what's the point of that, really? We already have the Apache community and the open source community. Why do we need another community within a community? What's the point of another layer of indirection? And if each codebase in jakarta becomes a TLP - wouldn't this be another level if indirection ? Apache community and open source community are all great - but both of them are one way or another an umbrella for multiple smaller communities. ASF is the real umbrella - not jakarta. Jakarta has multiple codebases and it started as an umbrella - but we managed to act and be perceived as a community. Not a perfect community. And look what's happening with logging: Now that it's a TLP, they are bringing-in the various Log4J compatibles. Now, there can be one Apache logging project serving every platform. That's community-building! Is logkit included in the logging TLP ? What about commons-logging ? I agree with you that the logging TLP does define a community ( just like jakarta or httpd ). It's a separate PMC bringing togheter different codebases and people. It remains to be seen if log4j as a TLP will be better than log4j as part of jakarta. There are plenty of TLPs - like apache-commons - that don't seem to be much better than sub-projects like jakarta-commons. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Bill Barker wrote: I'm sure that Craig or other will correct my mistakes (I haven't been here quite that long :). Jakarta started as Tomcat and friends after Sun donated Tomcat to the ASF (hence the name 'Jakarta' :). As the project grew (sign of success), Jakarta grew to include projects that don't necessarily rely on Tomcat (but could be used with), nor that Tomcat relies on. This has been the traditional server-side-java test. Now, Jakarta has been having projects that want to leave to ASF-TLP status (e.g. log4j, ant, maven, james). This is calling into question what the 'Jakarta' name stands for now. What this thread is about is trying to answer this question: what, if any, is the mission of 'Jakarta' going forward. I think Tomcat and friends remains an excelent definition :-) ( it's the friends part that is important - tomcat just happens to be the first project in jakarta :-) Costin - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 9:11 PM Subject: Re: Jakarta: Confederation or Single Project? Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
robert burrell donkin wrote: On 4 Dec 2003, at 22:35, Andrew C. Oliver wrote: snip From a Jakarta PMC perspective, I think that we should cease to support Sub-sub-projects with the exception of commons.* i think that it depends on what's meant by sub-sub-projects :) i'm happy for a single sub-project to create many different products (by this i mean stuff it releases). so, component repositories like jakarta-commons are fine by me. (some people describe these products as sub-sub-projects.) but i think that each sub-project should only have one list of committers (though for reasons of security, if a sub-project has more than one repository, karma for a repository may be given out only on request) and one development mailing list. so i'd like to prohibit any sub-sub-projects like jakarta-turbine-JCS. Or even better - since jakarta has a single PMC, it could also have a single list of committers ( most of them in the single PMC ). Each PMC member can vote about any jakarta issue - including releases of each sub-project, etc. If the distinction between pmc and committer is fading, then I don't see why do we have to worry about separate karma. A start could be to have every PMC member have karma in every subproject. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Henning Schmiedehausen wrote: On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. +1 but direct drop only if the move to the commons is accompanied by a release (1.0 or 0.something, I don't care). Else it would not be fair to many other sub-projects currently in the sandbox which have been kept there because there is no release (commons-configuration e.g.). There is also the problem of external dependencies ( if any ). At least some of the people on commons preffer commons as more-or-less standalone tools, that don't require a lot of 'framework'. I don't know JCS, but if it can be used as a standalone library - it would be great to get it into commons. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] SuperXMailer
You did actually create a sourceforge project for this joke ? Costin Andrew C. Oliver wrote: Hi All, I'm pleased to finally propose the SuperXMailer for Jakarta via the incubator. I'd like for the Jakarta PMC/committers to vote a tacit approval of the project before we work on acceptance into the incubator. I'm sure that despite the inevitable controversy, folks will see a true value in this project and its active community. Unfortunately the source repository and mail archives are down at the moment, but I'm sure they'll be restored soon. Note that there is also something strange with the bug database. We now have email deobfuscation which defeats schemes like [EMAIL PROTECTED] and such, as well as acoliver at apache dot org. No worries, the mail will be harvested and get through! Thanks for your consideration. Please feel free to submit your vote in advance. -Andy http://nagoya.apache.org/wiki/apachewiki.cgi?SuperXMailerProposal [0] rationale SuperXMailer, the project hosted at http://sourceforge.net/projects/superxmailer/ is a tool for harvesting email addresses from web pages and mail lists, storing them in any database or XML file, and sending them email addresses. It features opt-out lists, email verification and much more. The project is the creation of a number of Apache committers and is run as a meritocratic community-developed project. Presently the CVS repository and mail lists are down (as of 3/30), but we have opened up a support request and will have it up again soon. [0.1] criteria Meritocracy: SuperXMailer follows the Apache meritocracy rules, with a core of committers including ASF members. Community: SuperXMailer has a modest, but very active community. Its users are very pleased with its performance and capture capabillities. Core Developers. SuperXMailer has an active and dedicated team of committers. The project was founded by Andrew C. Oliver, who is extremely dedicated to SuperXMailer and authored the majority of the codebase. Nicola Ken Barrozzi and Glen Stampoultzis are frequent contributors of components and bug fixes as well as some significant extensions. Sam Ruby has offered to provide Web Services extensions via Axis. Alignment: SuperXMailer makes use of Lucene, POI, Struts, Velocity, Turbine, Xerces, Tomcat and Xalan. Scope: SuperXMailer is entirely a server-side application, well aligned with the overall goals of the Jakarta project. [1] scope of subproject The project shall create and maintain packages written in the Java programming language constituting the framework, management tools, search/database and mailer, a standard library of additional components, documentation, a web site and additional examples. [2] identify the initial source from which the project is to be populated The project currently resides on the SourceForge (http://tapestry.sf.net). [3] identify the Jakarta resources to be created [3.1] mailing lists(s) superx-user superx-dev [3.2] CVS repositories jakarta-superx [3.3] Bugzilla framework - superx components - web site, contrib library, documentation, examples [3.4] Wiki The SuperXMailer developers would like to make use of the ApacheWiki in order to facillitate the admittedly spartan documentation. However, its extremely easy to use. Many Apache committers have received mail from persons using it with great results. [4] identify the initial set of committers (Any Jakarta commmitter is welcome to add their name here) Andrew C. Oliver Nicola Ken Barrozzi Glen Stampoultzis [5] identify apache sponsoring individuals (Any Apache member is welcome to add their name here) Andrew C. Oliver Nicola Ken Barrozzi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XDoclet, XJavaDoc, Apache and Licensing
Aslak Hellesøy wrote: The XDoclet project (http://xdoclet.sourceforge.net/) is considering applying for Jakarta/Apache membership. Glad to hear that ! We believe that these differences are sufficient in order to avoid potential licensing problems with Sun. I'm not sure I understand where the licensing problems would come from. Are you using any code from javadoc or Sun ? Are you implementing any Sun APIs in XJavaDoc ? The only possible problem I can see is the name ( which is very close ). 1) Can anyone with more knowledge about licenses tell me whether XJavaDoc is in violation with Sun's license for JavaDoc? I don't have knowledge about licenses, but I fail to see how it could be ( unless you use some code or APIs from javadoc ). Maybe a trademark violation - if JavaDoc is tm. 2) Would it be fair to claim that XJavaDoc is *not* a clean room implementation of JavaDoc? That's something only XJavaDoc authors you can tell, and nobody else. If you used JavaDoc source code in creating XJavaDoc - then it can't be a clean room. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Andrew C. Oliver wrote: have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. My understanding is that the NDA prevent those in the JCP from sharing with the world - but AFAIK they can share it with other ASF members. If we could find a way to extend this to the whole PMC - then we can improve a bit the communication problem. Regarding the selection - I think it's up to ASF to set the policy on who will represent it in the various JCP groups. Right now it's whoever volunteers - which is reasonable. There is no ASF policy that I know about the responsibilities of those who represent the ASF in JCP - with regard to sharing the info with at least the members in the interested PMC - and I think this is a problem. As with any standard, the decision making is based on a group of people representing different interests. Apache does have a vote ( AFAIK ), just like Sun or IBM. Projects should be able to participate - and we should find a way to apply the apache meritocracy and community rules in our participation to JCP ( for example by a vote by committers who are affected or by PMCs ). In any case - your comment that the decision is made by a committee is right, and it is the way things happen in all standard organizations that I know. Even in Apache - the products are defined by a community of committers, and the decisions are made by a consensus or majority vote. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. The spec is approved by a majority vote. I don't think standard goal should be to innovate - but recognize common patterns and practices and set ground rules. As with any project - the quality of the participants and the quality of the communication has a big effect on the end result. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Andrew C. Oliver wrote: Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. I'm not against all standards...just NDA-based vendor baby kissing. Andy: Sun doesn't control, it has one vote just like ASF or IBM. ( at least AFAIK ). If the lead is an Apache representative he can choose open mailing lists - there are few JSRs that do that. I don't know if W3C or Ecma are using only public mailing list and no NDS - but I'm pretty sure there are enough big corporations involved:-) Costin -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][PMC VOTE] PMC Nominations
robert burrell donkin wrote: one of the problems we have in the commons is the number of votes which spawn threads which go on for ever without any clear conclusion. that's why i think that announcing clearly when a vote is finished is a good thing. IMO all vote results should be at least posted to the pmc list. The PMC should be able to at least review the results. Things like adding new dependencies to a project, moving code, releases, major changes need to be very visible to the entire PMC, even if few members are involved in each project. ( dependencies are particulary important, if they are not under apache-like licence ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][PMC VOTE] PMC Nominations
Jeffrey Dever wrote: Vote results? It unclear even when a vote is taking place and who the nominees are. I thought we just finished a round on the 19th with an Sorry, my mistake - I was thinking about all vote results in general, i.e. whatever gets voted on various parts of jakarta. The problem is that even on the projects that I track, it is sometimes difficult to figure out what was the vote result - after the vote text changes few times and people change their vote and so on. If the vote results would be posted to pmc ( or checked in some CVS or anything like that ) - it would be easier for all people to get an idea of what's happening, even in projects they're not directly involved. IT's not only for PMC - it is a useful information for everyone. Last week I was happy working on my project. Then I find out that voting rights on releases will be taken away unless I join the new expanded PMC. But the process appears to be in shambles. No vote right will be taken - quite the contrary :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PMC Nomination
Conor MacNeill wrote: purely PMC role. All releases of Jakarta sub-projects must be approved by the PMC. This isn't something that has been done in Jakarta to date, One good first step in this direction would be to at least Cc: the pmc list on all [Vote result] messages, so all pmc should be aware of the decisions made. I know there is no explicit rule for that - but it should be, at least for release votes, and all major decisions. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PMC Nomination
Geir Magnusson Jr. wrote: On Wednesday, February 19, 2003, at 12:18 PM, Sam Ruby wrote: Jeffrey Dever wrote: I am not excited by the idea of only PMC members voting on releases to the exclusion of active committers. I'm the release prime for Commons HttpClient where all committers vote on all issues all the time, including releases. HttpClient is somewhat unusual in commons as it is rather a large project with a dedicated mailing list and a rich family where many, such as myself, are primarily focused on just one project, HttpClient. The goal is to make all active committers PMC members. Would it be quicker just to make all active committers PMC members by default? I think the goal should be that the PMC should include all committers that are active and have been around for a while ( 3..6 months seems reasonable). I like the current system of proposing release managers - as it encourages people to do this work. Proposing people who are taking a very active role in various projects would also be good. I don't think all active committers should be PMC members by default - maybe after few months if they stick around and continue to be active. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PMC Nomination
Jeffrey Dever wrote: I am not excited by the idea of only PMC members voting on releases to the exclusion of active committers. I'm the release prime for Commons It is not to the exclusion of active committers. Http-client is part of jakarta-commons - and acording to the charter any jakarta-commons committer ( which is close to all jakarta ) can vote. As you probably know - only those who are really interested do that. I agree that we're not yet ready to have PMC votes on releases - we need to expand the PMC and include more people. Even when this will happen, I think the committer votes should be counted as well. At least for jakarta-commons - the difference will be insignifiant. The new group of committers has really risen up out of the ashes of the old HttpClient which became quite idle over the first half of last year. These new committers are what makes HttpClient move forward, and I cringe at the thought of taking some, any, responsibility away from them, away from us. Think of this in terms of a larger us. By beeing part of jakarta-commons, http client is already a part of a very large us, almost as wide as jakarta. In all cases - the responsibilty stays with the people who chose to be involved. That can include jakarta PMC ( most of the pmc is already committer on jakarta-commons anyway - so that means absolutely no change). As active http client committers join the PMC - they'll be able to assume more responsibility. Costin I am quite happy with how things are going right now. Our contributor base continues to grow and we are back to doing releases (hurray). We are using maven to build, have factored out some services into the Codec subproject and are looking to factor out URI into a new subproject. We have over 250 Junit tests, are using commons-logging and have reached critical mass to support our own votes according to Jakarta guidelines. Some complain at our isolation, but I see this as desirable given the size of the codebase and the volume of email traffic (approx 400/month). Of course we have an open door policy and have good connections to those projects that are connected to HttpClient, such as Slide, Cactus and othes both inside and ourside of Apache. There have been transitional pains, and growing pains, but all in all, I would say that HttpClient is a very healthy project. To quote the quote of Sam, Jakarta ... becoming a single community. I like the sound of this, but please consider that communities are composed of families that a) are all members of the community, b) interact more frequently with their own family members than others in the community, c) may or may not share culture and d) a single family has differing relationships between families. HttpClient has all the characteristics of a family in a community. I don't want to see this relationship disrupted by taking voting power away from the family representitives, the committers. I have not shown interest in the PMC up untill now, but it sounds like my family is at risk, and I'm concerned. In general, I just want to write code and progress HttpClient (of which I don't really have time for even this, but I like it so much I make time). I don't appear to have been nominated (or have just shown up on the list like Stephen) but I am eligible (committer, release prime and active for 10 months). Should I be seeking a seat on the PMC? Jeff (Jandalf) Dever. HttpClient 2.0 release prime. Conor MacNeill wrote: Stephen Colebourne wrote: Unless I am mistaken, being a PMC member implies an overseing role for the whole of jakarta, No, not quite, IMHO. The PMC as a *whole* has an oversight role for the whole of Jakarta but individual PMC members do not need to oversee all of Jakarta. In fact this is the nub of the reorg issues which have been floating around. AIUI, the 7 member PMC approach was felt not to be able to adequately cover all of Jakarta and the PMC must grow to adequately provide oversight. Eventually most consistently active committers will join the PMC. This is the httpd model, for example. Sam is moving from where we have been to that point in a series of steps. a requirement to follow PMC issues and votes and to be a manager. Whilst the concept of being able to push forward jakarta, JSRs, make decisions etc is appealing, I do not believe that I have the time available to do the job. Hell, I already lack the time to fully oversee the commons-lang, commons-collections and commons-clazz projects that I am involved with as I would like :-) If you are providing oversight of these projects, even to the extent you have time available, you are already filling one of the roles of a PMC member. If you have acted as a release manager, then you have performed a purely PMC role. All releases of Jakarta sub-projects must be approved by the PMC. This isn't something that has been done in Jakarta to date, really, but
Re: PMC Nomination
Pier Fumagalli wrote: ... Now, under Jakarta, there might be projects on which one might like to be involved and spend time on (therefore bearing the responsibilities of being a PMC member over _that_ particular code base), but there might be project that one don't want to be even remotely associated with... So, unless this: The PMC is responsible for the strategic direction and success of the Jakarta Project. This governing body is expected to ensure the project's welfare and guide its overall direction. Found here http://jakarta.apache.org/site/management.html Changes to identify that individual PMC members might have oversight only on a fraction (subproject) of the whole project, I would be against it. I don't know any plan to change the charter - the PMC is and will be responsible for the entire Jakarta Project. I'm also against any other fraction or fragmentation ( it seems we agree sometimes :-). The fact is that jakarta needs to become and act as jakarta community - and everyone who preffers a different community can do that easily. Having all people who are actively involved in jakarta subprojects participate in the management and oversight of jakarta is the right thing to do. We do have many different codebases and projects - but in the end they all fit togheter pretty well, and so do the people :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
Andrew C. Oliver wrote: ASF members that wish to be more directly involved in this issue can subscribe to [EMAIL PROTECTED] Before anyone asks, yes, this is a subscriber moderated list. Note that I don't object to such a list being that way. :-) I do :-) ( last time I checked - it was ASF members, not committers - and committers are supposed to know the licenses too ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Maven as a top-level apache project]
Jason van Zyl wrote: Gump _never_ used an object model, never. Gump was targeted at overall control by a small set of people (and it's still that way, no one outside of Jakarta/XML barely knows what it is) to build sources against CVS. That's not what Maven was ever targeted at, ever. Maven uses Ant but Ant has no concept of an object model either. I definitely admit to not wanting to use the Gump descriptor and that's proven to be a good thing. If you call Maven a duplicate of a tool that generates 30k line shell scripts then do as you please. So what ? The point is that setting a standard for the repository and descriptor should be apache wide. What is used to implement it is completely irrelevant. The descriptor and repositories consist of files and protocols - that can be implemented in gump, ant or plain java. _before I ever knew of Maven_ That's fine. Don't presume to know how long I've been thinking of Maven before the first line of code landed anywhere. This is not a contest of who tought first - you're not getting a pattent. People have been thinking about CPAN/CJAN and build tools for a long time, and what matters is finding a common solution that is independent of a particular build tool. Give me a break. Again like a pluggable functionality is a radical new idea. Your plugins are ant build files. So you came out first with a way Like a CPAN repository or dependency tracking is a radical new idea... I don't care what you do or do not do. I didn't want any part of Gump code, 30k lines shells scripts, a DOM model or a big heap of ant build files. So yes, I am the one who advocated not working together but I certainly wasn't the only one who felt like that. There are people who don't care of Maven code too - I use Ant and I'm happy with it. I care about a standard descriptor, layout and repository - and that standard can only happen if it is accepted by all tools and projects. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Maven as a top-level apache project]
[EMAIL PROTECTED] wrote: Costin, what's a 'maven-only' repository? There are at least 3 build tools in apache: ant is one of them, gump and maven ( there are more actually ). There are many projects whose releases will be in such a repositroy. The policy and the format of the descriptors must be set in an apache-wide project. I know that the files and descriptors on ibiblio are available to everyone. Just like sourceforge downloads and mirrors are available to everyone. My point is that an apache repository and the descriptors and layouts that will be used in apache need to be a project that is common to all build tools and with a bigger community than Maven has ( i.e. including Nicola and Sam Ruby and ant people - and much more ). Costin -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au news [EMAIL PROTECTED] wrote on 07/02/2003 04:53:05 AM: Sam Ruby wrote: Those that care to participate, please indicate your interest by posting to the [EMAIL PROTECTED] mailing list. It's up to the board members to decide - but as with Nicola's proposal, I'll strongly opose ( by not participating :-) a repository/CJAN/etc project that is not open to all apache committers ( like gump for example ). Maven is a nice tool - and I wish it good luck wherever it goes. But if Maven charter will include the creation of a maven-only repository - I hope at least some board members will vote -1. Costin Original Message Subject: Maven as a top-level apache project Date: 06 Feb 2003 12:20:32 -0500 From: Jason van Zyl [EMAIL PROTECTED] Reply-To: Turbine Maven Developers List [EMAIL PROTECTED] Organization: Zenplex Newsgroups: gmane.comp.jakarta.turbine.maven.devel Hi, As I've just gone through the process of getting db.apache.org of the ground I would now like to attempt to do the same for Maven. A top-level project could house Maven and ancillary tools like Continuum and an SCM package and various IDE integration that are popping up. I can easily mock up a site as I'll just borrow the tools I made for db.apache.org. There is a board meeting in two weeks so if the developers are in agreement we'll try and go straight to the top. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ForwardSourceID:NT000ADF56 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Maven as a top-level apache project]
[EMAIL PROTECTED] wrote: Sure, but let's not lose focus of what this is for. Distribution? Building? A company/individual can set up their own repository of jars (we all do) that they've accepted licenses for. The 'tools' should be able to work with that set up, similar to how Maven does today. True. That's exactly my point. We need an Apache repository and a set of tools to be used in apache - and this should work for all projects and build tools that are in apache. We need a standard layout and descriptors for dependencies - but this needs to be agreed on by all involved. If maven scope is to create a build tool - that's perfect. If maven scope is both a build tool and an apache repository and non-apache repository and defining standards for other build tools - that's not good. Probably it would be a good idea if someone with experience in a standard process would get involved in the repository and descriptors- Geir or Craig would be great ideas ( I know many have issues with the JCP - but the fact remains that setting any standard is different than writing code ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
+1 ( a bit too long, but good !) Costin Rodent of Unusual Size wrote: okey, i'm wading in here, noting as i do the angels high-tailing it in the other direction.. :-) i'm ccing community@apache because i think portions of this discussion are important to the entire asf developer community, and not just jakarta. (jakarta leads the way again! grin nature=completely non-hostile/) this is my take on the things we need to keep in mind. i may be wrong; where i'm unsure, i'm erring on the side of conservatism. and i'm saying this stuff with my board hat semi-on; that is, i'll be glad to be corrected or overruled by the rest of the board, but in the absence of such i'm breaking new ground with a tentative prototype policy. it's all open to discussion and refinement, but it's semi-official. it's just my take on things at the moment, but it's a stake in the ground. now, then. the (at least!) two things we need to keep in mind are: 1. no asf package (or asf contributor acting ex officio being an apache contributor) may deliberately violate the terms of any licence. 2. no code nor activity is permitted that will virally infect any of the asf's assets, or those of any user of asf packages. those are pretty much non-negociable; any inadvertent violation needs to be corrected AT ONCE as soon as it is identified. violating a licence because 'everyone else is doing it' or 'the licence-owner has never gone after anyone' are not on; we need to do the Right Thing, not the cop-out or expedient one. if, for instance, we violated one of microsoft's licence terms just because everyone else does, the potential harm to the asf is enormous: not only massive monetary liability, but severe damage to our reputation for integrity. so we must not distribute any 3p (third-party) packages from asf systems if it is not permitted by their licences. nor may any of our code automatically go off and fetch such packages and start using them on the user's system if the packages' licences require *any* sort of acknowledgement by the user. that is, if the licence for package 'x' says the user must stand on its head and send a paypal donation before using 'x', none of our code may automatically download 'x' to the user's system. if it's *already* on the user's system, we can use it -- but we can't get into any position in which we are essentially responsible for transmitting someone else's licence terms to the user, and assuming they've agreed to comply with them. (i.e., for now i'm ruling click-through licences as not permissible for our stuff to present.) as far as sun-bin licensed stuff on ibiblio -- it's not an asf system, so the asf is neither liable nor responsible. *if* some asf package requires sun-bin stuff, and silently goes off to ibiblio to download it, though.. that's not allowed. telling the user it needs to download the sun-bin stuff is fine; telling it the stuff can be found on ibiblio.. well, i *think* that's okey, but it's kinda grey. if someone is using an asf package that does *not*, itself, require such stuff, but is using the asf package to build something that does, i think we're pretty much okey there too, since the user needs to explicitly state the dependency. i think it's possible to consider stating the dependency as equivalent to having the stuff already on the system -- but again it's a grey area, and i hope roy can shed some light in this darkness. again, autofetching it by default from a known location -- such as ibiblio or sun -- once the dependency has been stated by the user *should* be okey. i think. i'm not even going to touch the infection issue at this point; it always makes my cephalic nodule hurt horribly. let's just say that we can't do anything that will trigger an infection of the asf's assets -- or those of someone using asf packages. if a licence permits *linking* against a library, there's no prohibition on our packages requiring the library in order to run properly. if a licence allows us to include the library, as a general rule we can package it with our stuff. if by linking with it or including it in our distributions we trigger a clause in its licence that either overrides the asf licence on our stuff, or forces the user to comply with rules more restrictive than the asf licence.. then we mustn't do that. i hope this all makes sense, to some degree. please follow up to [EMAIL PROTECTED] and because recording incremental advances before a final policy is published seems like an appropriate use, i've set up http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing as a work area where we can distill the rules before they get finalised and formally published on www.apache.org. i need to stress that the wiki page is for *recording*, not discussing. if someone wants to take a look at the current state of things, the wiki is good method -- but hammering out
Re: [Proposal] Jakarta Ruper
I'm +1 overall - but I have few sugestions and proposals.
First: if it will be a jakarta project, I would like it to be all-jakarta,
like gump - any jakarta ( apache ) committer should have access to it. I
consider this an requirement ( I won't vote +1 without this ). I think
that jakarta should become a single community, and I see no good reason
for a project like that ( which affects the entire jakarta and more ) to
not be jakarta-wide.
I am not very happy with the maven layout - which includes only jars.
If this is aproved - I would like it to require a layout that supports
all project components. I assume ( hope ) that part of this project
will be an effort to convert jakarta projects to this layout, and also
make the necesary changes to gump to generate output for the repository.
Costin
On Wed, 5 Feb 2003, Nicola Ken Barozzi wrote:
http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
I've set up a proposal about a Jakarta project for a Repository Project
on the wiki. Below is the current content.
Maven developers are invited to partecipate in the effort :-)
Cheers!
'''Proposal for Apache Jakarta Ruper, A Java Resource Repository
Subproject'''
''5 February 2003''
'''(0) rationale'''
Advanced build systems like Maven and Centipede use a system to download
project dependencies at need, instead on relying them to be in CVS. This
has evident benefits, including less bandwith and disk space usage, and
better and easier project and repository management.
'''(0.1) criteria'''
Meritocracy: Design decisions have been made following the Krysalis
Community project Guidelines, that are very similar to the usual Apache
project guidelines.
Community: There is a growing community of developers that are using the
code in everyday projects.
Alignment: Uses many Jakarta components, and is compatible with Maven
repositories.
Scope:
* Versioning
* Dependencies
* Reposistory mangement
* Downloading of jars.
'''(0.2) warning signs'''
Orphaned products: Ruper is alive and used in Centipede, which is used
to build OS projects.
As for
* Inexperience
* Homogeneous
* Developers
* Reliance on Salaried Developers
* Ties to other Apache Products
* Fascination with Apache Brand
Krysalis Ruper is developed and maintained by Apache developers, that
wish to bring this effort inside Apache itself.
'''(1) scope of the subproject'''
The purpose of this subproject is to create and maintain an
implementation of a repository for resources, dealing with versioning,
dependencies, and usable by the widest possible range of build tools.
Mirroring and alternative ways of distribution are to be strongly pursued.
'''(2) identify the initial source from which the subproject is to be
populated '''
*
[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/krysalis/krysalis-ruper/
Krysalis Ruper]
*
[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/metamorphosis/krysalis-version/
Krysalis Version]
* [http://jakarta.apache.org/turbine/maven/ part of Maven ?]
'''(3) identify the ASF resources to be created '''
'''(3.1) mailing list(s) '''
* ruper-dev
* ruper-cvs
(no user mailing list yet, we are starting at Jakarta)
'''(3.2) CVS repositories '''
* jakarta-ruper
'''(3.3) Bugzilla '''
* jakarta ruper
'''(4) identify the initial set of committers '''
* Nicola Ken Barozzi ([EMAIL PROTECTED])
* Nick Chalko ([EMAIL PROTECTED])
* Adam Jack ([EMAIL PROTECTED])
* Ted Leung ([EMAIL PROTECTED])
'''(5) identify apache sponsoring individual '''
* Andrew C. Oliver ([EMAIL PROTECTED])
* Nicola Ken Barozzi ([EMAIL PROTECTED])
'''(6) open issues for discussion'''
* Some Maven committers are interested in contributing Maven code for
this effort.
* The name is still to be defined. Ruper is the current name, but it can
be anything elso. Suggestions:
** '''Jakarta Ruper''' ('''R'''esource '''UP'''dat'''ER''')
** '''JRAN''' (Sorta like CPAN)
** '''Jakarta Lean'''
*** Lean as in smaller becuse there is no jars in cvs.
*** Lean on me - to help you find your jars.
** '''JPM''' (Jaava/Jakarta Package Manager)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Jakarta Ruper
Nicola Ken Barozzi wrote: I would sugest proposing Version to ant. Why? It seems to me that versioning and resource updating-retriving is really tied together. Why Ant? If it gets included in ant1.5 - more people will have access to it by default, and more likely will be for other projects to use this. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Jakarta Ruper
On Wed, 5 Feb 2003, Andrew C. Oliver wrote: I am not very happy with the maven layout - which includes only jars. If this is aproved - I would like it to require a layout that supports all project components. I assume ( hope ) that part of this project will be an effort to convert jakarta projects to this layout, and also make the necesary changes to gump to generate output for the repository. Here is my 2c. All the big dream attempts at this have failed. So starting with maven's approach and growing into the big dream seems the most sensible model. There are obvious problems with maven's approach, but the fact that it actually works is the cutting board. From there though, eventually the approach will improve itself through the normal benefit of real people with real problems solving them. +1 As long as we agree this (current maven model) is the start, and not the end :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal
Andrew C. Oliver wrote: Can't do it. I will never collaborate on anything with Nicola Ken Barozzi. And if I have to say it in public I will. I would probably participate in anything but not with him. wow... :-( I don't know what wow means - but it is absolutely normal for any community. I'm sure there are people who don't like working with me ( or anyone else )- and the reverse. I don't think anyone can reasonably expect anything else. What's important is for everyone to keep having some fun and decide for himself if beeing in a community like jakarta ( and benefiting from the diversity of opinions and ideas - even from people we don't like ) is worth the effort of dealing with the people we don't like ( or strongly disagree with, or both ). As ( and if ) jakarta becomes a single community - everyone will have to deal with this decision. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
The only problem is that Tapestry originally had a special, built-in web page for creating Log4J loggers (nee categories), and changing Log4J levels (nee priorities). This used addtiional methods in Log4J Logger for setting the level, and elsewhere for creating new loggers. The commons-logging folks are pretty adamant that extrending the framework for these operations isn't appropriate. (I disagree, but it's not a fight I'm prepared to wage, or expect to win). I agree with you - partially. We should have a config mechansim - but it shouldn't be part of the core logging interfaces. I would vote +1 on an optional interface that allows some basic configuration ( like setting the level for a category ), but I don't think it would get a majority. My prefference is JMX for configuration - log4j already has some support for that, and it would be possible to create mbeans to manage jdk1.4 logging as well ( or other logging impl. ). It is on my todo list ( next to using JDNI java:env/ to select the logger implementation ) - but I don't have the time right now. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Stefan Hepper wrote: - Pluto is only the reference implementation for the Portlet API defined in the JSR 168 This is comparable with the tomcat being the servlet container and implementing the servlet API. Pluto itself is only a infrastructure component. All portal related functionality like aggreagtion of the output of different portlets, authentication, etc. is NOT part of pluto, but needs to be provided by the portal calling pluto (e.g. JetSpeed or Coocon). Well - tomcat implements servlet API and JSP, but technically it is not the actual reference implementation, it is used in the RI ( J2EE RI AFAIK is considered the RI for servlet/JSP ). And tomcat implements a bit more than just jsp/servlet - it has admin interface, CGI and SSI support, WebDAV and its own extension APIs. Same can be said about most other projects that implement APIs ( xerces, xalan, axis, etc ). - Why is Pluto not part of JetSpeed? Pluto has a very restricted scope and is an infrastructure componentet that can be used from serveral other projects (e.g. Cocoon and the proposed Charon). The Portlet API is defined by the JSR and cannot be changed and therefore differs from what you can do in JetSpeed, where you can freely define your API. I could easily see a situation where JetSpeed wants to provide additional functionality beyond the JSR 168 1.0. If these are different sub-projects this is easily possible: JetSpeed could just take Pluto and add functionality. The API defined in a JSR can't be changed - period. Jetspeed can't take pluto and modify some APIs if he wants to - that would be wrong and against the JSR rules. If Pluto community decides to provide additional features, like integration in cocoon/struts/etc - I don't see what would stop it and why this would be a bad idea. Maybe my question was wrong - the problem is why Pluto and JetSpeed ( and other portlet efforts ) are not in the same community ( with a single portlet related mailing list ) ? - Relation to other Apache projects: JetSpeed and the Coocon portal framework plan to use Pluto (Carstten Ziegler just asked me to include him on the committer list). As Portlets are Web components that may be bundled with other web components, like servlets/JSPs, Pluto will be build ontop of Tomcat. Struts, JSF, and other web frameworks: Portlets sit in front of these frameworks. Each portlet can be viewed as a special web application that is rendered together with other applications on the same page. The portlet API provides the portal a standard way to call these applications. Each portlet is free to choose how to implement the logic and rendering inside: using JSPs, Struts, JSF, XML, ... I would preffer that all portlet-related technology would be in the same project and community, with JSP/struts/cocoon specific areas. Maybe an commons-like project. Please don't treat my questions as oposition to Pluto proposal - I think it's a good thing and I would be happy to see it in Jakarta. I just think it would be better for pluto and portlets in general if a bigger community would be around it and all rendering frameworks would cooperate ( at least in support for portlets ). That could result in a consistent portlet support, or at least some sharing of ideas - and get enough review to whatever happens there. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Forum Software.
James Mitchell wrote: So the suggestion is: All Users lists become forums. Developer lists stay. I will fight to my dying breath to make sure this DOESN'T happen (with what little persuation I can muster). I have come to rely deeply on these lists. +1 I spend my offline hours (daily commute, boring meetings, vacations, etc) going over the list discussions. I have accumulated a large amount of data that I transform into documentation just from this single source of knowledge transfer. PLEASE PLEASE PLEASE DON'T DO THIS! Same here. Costin Only problem I see there is that Developers won't check the forums as much as they should, unless the Users forum has a mail list interface. Hen On Wed, 22 Jan 2003, Robert Simmons wrote: Well, once again I would like to bring up the concept of forum software for Jakarta. The reason I am bringing it up again is that mailing lists are intrusive and spammy. Daily I get flooded with a ton of email that I have absolutely no interest in reading. However if I unsubscribe to the lists than when there is something that I would like to know about or answer, I will miss it. In addition, if I unsubscribe I'm not able to post my own issues. With a mailing list, the communication mechanism is just too intrusive. On a forum I can pick and choose what I want to read and reply to. As for them being used, its a simple matter of retiring mailing lists for forum software. When we consider that at least 90% of Jakarta users are not Jakarta developers but will often have a question or an important insight, than the folly of communicating only in mailing lists becomes clear. -- Robert Simmons -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org/ The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain (1835-1910) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Alex McLintock wrote: At 17:41 21/01/03, you wrote: One more question: why not doing this as a subproject of JetSpeed ? It is an existing jakarta project, the scope matches - why creating a separate jakarta community instead of joining the existing one ? I assume that it would be a tool which could be used by the Cocoon portal system, and a Struts portal system as well as Jetspeed which is essentially a Turbine portal system. People may want to use this component without using Jetspeed. Of course I haven't read the JSR yet. My understanding was that Jetspeed goal is to implement a portal - with Java and XML. I would rather see all portal systems sharing a single community and implementing similar behavior/standards - rather than have one portal for each technology ( struts, cocoon, turbine, tapestry, plain JSP, plain servlet, whatever else toolset ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PMC VOTE] PMC Nominations
+1 for all. +1 for Glen Stampoultzis ( cutpasted last name :-) and Robert Burrel Donkin. Costin Sam Ruby wrote: Reorging the Jakarta PMC apparently has become an annual event. This year will be no different. I've had lengthy talks with the Apache Board, and this has caused me to revisit a number of assumptions. Looking at http://httpd.apache.org/contributors/, it is clear that the ASF concept of a Project Management Committee permits a significantly larger number of PMC members per project than I, at least, had ever presumed. Given the success that Jakarta has had to date, I don't want to propose any rapid, irreversable, or disruptive changes. But the goal should be clear: the PMC should consist of *all* the people who are actively and consistently monitoring the code. So for the first step, I'd like to nominate the following individuals who have contributed multiple times to the Jakarta newsletter and/or recently served as a release manager of a Jakarta subproject: [ ] Nicola Ken Barozzi [ ] Stephen Colebourne [ ] Martin Cooper [ ] Henri Gomez [ ] John Keyes [ ] Larry Isaacs [ ] Otis Gospodnetic [ ] Thomas Mahler [ ] Remy Maucherat [ ] Glenn Nielsen [ ] Andrew C Oliver [ ] Rob Oxspring [ ] Martin Poeschl [ ] Scott Sanders [ ] David Sean Taylor [ ] Mladen Turk [ ] James Turner [ ] Henri Yandell Future steps will include introduction of a concept of an emeritus PMC member, reinstating prior PMC members who are still active, and more nominations (particularly those that chose to contribute to the newsletter, and/or act as release manager, hint, hint). Longer term, the plan is to move the subprojects that chose to remain in Jakarta towards becoming a single community - in particular release votes will become a responsibility of the PMC. That does not mean that all PMC members will vote on all releases, but that it will be from this pool of members that release votes will be cast. Clearly there will need to be a number waves of additions like the one above to the PMC before we get to this point. Meanwhile, my plan is to see to it that those subprojects that desire to become ASF projects will get the full cooperation and support of this PMC. Now for some fine print: * nominees may chose to decline without giving any reason * only current PMC member's votes are binding * once the vote completes, PMC membership is not effective until 48 hours after a board member acknowledges receipt of these votes. Let the voting begin! - Sam Ruby P.S. My vote is +1 on all. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta PMC report
Jon Scott Stevens wrote: BTW - thanks for taking the time to fix the bugs in regexp, and congratulations to the jakarta-regexp team for completing the project ! :-) Thanks for being a complete idiot Costin. I meant it very seriously - I think every project should have a goal, and should eventually reach the goal in a finite amount of time. The fact that jakarta-regexp just works and has met its goals is a very positive thing. And the team that worked on it deserve ( sincere ) congratulations ( including you, Jon ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [discussion] jakarta-gump as community property
Sam Ruby wrote: Gump is now two years old. It has had contributions from over a dozen people, about a half-dozen this month alone. There seems to be a renewed interest in gump (some in response to a little nudging grin). Considering all of this, what I would like to propose is that the contents of jakarta-alexandria/proposal/gump get moved to jakarta-gump, all committers to any jakarta code base be given karma and voting rights on the full contents (descriptors, code, and stylesheets alike) and that a single [EMAIL PROTECTED] mailing be created (we are all devs here, right?) Thoughts? Big +1 Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta PMC report
Jon Scott Stevens wrote: on 2002/12/19 8:04 AM, Costin Manolache [EMAIL PROTECTED] wrote: I meant it very seriously - I think every project should have a goal, and should eventually reach the goal in a finite amount of time. The fact that jakarta-regexp just works and has met its goals is a very positive thing. And the team that worked on it deserve ( sincere ) congratulations ( including you, Jon ). Costin Yup, just like Tomcat 3...which should have reached its goal years ago. Yes. I personally think tomcat3.3 has reached its goals ( performance, modularity, simplicity, compliance, etc ). The time it takes to reach the project goals depends on many factors. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta PMC report
Whenever you feel the time is right, you have my +1 :-) It would be great if it would be added in jakarta-commons. Costin Ara Abrahamian wrote: XDoclet (xdoclet.sf.net) also has some plans for moving to apache. I kept an eye on Tapestry's transition process. I'm not sure when it's the right time to officially propose it. So what are the plans for Jakarta? When is this reorganization phase completed? When is it the right time for XDoclet to put the proposal forward? Ara. -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 7:07 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Jakarta PMC report The status report for Jakarta project is available at http://jakarta.apache.org/site/news.html and http://jakarta.apache.org/site/news/index.html. These summaries are community developed, monitored, and maintained. Feedback on their contents should be directed to mailto:[EMAIL PROTECTED]. I tried unsuccessfully to summarize the summaries without looking like I was trying to prove a point about it not being a good idea. Of course, this begs the question about what happens when Jakarta is split up and all this data feeds directly into the board, but I digress. Overall, the imperialistic expansion phase of Jakarta has been put on pause. No new code bases have been accepted. Two colonies, Ant and Avalon, have split off successfully. The only issue in this area is Tapestry which unfortunately has been left in limbo in the process, neither accepted by Jakarta nor by the Incubator. The biggest unresolved issues in Jakarta deal with codebases on either end of the maturity spectrum. There are code bases which seen to be perennially in alpha, and therefore feel the right to change interfaces on a whim and without regard to the community impact of such changes. Unfortunately, the existence of a sandbox seems to have institutionalized this policy. Unquestionably, code bases in alpha should be allowed to experiment, but the establishment of a playground where this takes place indefinitely is not in the best interest of the ASF. On the other end of the spectrum is codebases which have matured to the point where there aren't enough itches to scratch to maintain a development community. Such codebases (for example, regexp) are heavily depended upon and so interwoven into the fabric of many Jakarta subprojects that it is hard to imagine removing then from the ASF despite the somewhat different community dynamic one sees thre. There isn't even a quorum to hold a proper release vote or people actively monitoring the bug reports and commits. This is a problem. -- To unsubscribe, e-mail: mailto:[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]
Re: Jakarta PMC report
Jon Scott Stevens wrote: on 2002/12/18 7:36 AM, Sam Ruby [EMAIL PROTECTED] wrote: Such codebases (for example, regexp) are heavily depended upon and so interwoven into the fabric of many Jakarta subprojects that it is hard to imagine removing then from the ASF despite the somewhat different community dynamic one sees thre. There isn't even a quorum to hold a proper release vote or people actively monitoring the bug reports and commits. This is a problem. Hey, I resemble that remark! The fact of the matter is that I have picked Regexp back up and have recently applied a bunch of bug fixes and closed a number of open issues (I spent about 1 hour on it). I think the point was that we also need people to review the commits and people to vote on the release. 20th), I plan to spend another couple hours and make one final release of Regexp. At which point, I'm going to call the project 'final' and Jakarta can figure out what they want to do with it from there. Previous ideas included just moving it to be distributed under the ORO project which I think is a good idea and will remove some confusion. I will probably be willing to help with that. I don't know what final would mean - if bugs are found that affect projects using regexp ( like tomcat which AFAIK has a dependency ) - then I hope it'll still be possible to fix them. My opinion about stable projects like regexp: we should change the avail to include the whole jakarta ( similar with jakarta-commons ). This way any project that has a dependency on regexp will be able to protect itself and either fix the bugs that bite them or review changes that may break something. BTW - thanks for taking the time to fix the bugs in regexp, and congratulations to the jakarta-regexp team for completing the project ! :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The organization of xml.apache.org
On Mon, 2002-12-02 at 16:41, Sam Ruby wrote: Separate code bases with separate communities should be separate projects. Independent of the size of the codebase, if the size of the community is only a few people, then it is not an ASF project. Such efforts can be pursued outside of the ASF, be pursued inside the Incubator, or be incorporated inside an existing community as long as all participants in that larger community are treated as peers. With respect to XML, I honestly don't know how many communities we have. But the above provides a recipe to find out. Without changing any physical layout of mailing lists or cvs repositories, we can begin to phase out the karma and voting boundaries between various subprojects. Those that don't wish to participate will be encouraged to form their own separate projects (or move into incubation). What I like most about such a proposal is that it is completely up to the commiters to decide whether they want opt in or opt out. What do others think? ( I changed the to: to include jakarta :-) I think it is a good idea in general, as long as it is done gradually. I personally think jakarta-commons commit model works fine ( even if the one-mailing-list is not working as well :-). Even when it didn't seem to work that well ( early days of xml-client for example ), it actually did work as it was supposed to, and I think people learned to keep track of what they need and use their vote. Probably having the walls removed between projects that are close ( tomcat/jasper and taglibs or struts, etc ) would be a good start. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mozilla mail filters
Pier Fumagalli wrote: Does it use the same mail verification program? Messages are delivered to my Qmail, will through SpamAssassin and McAfee for viruses, if that's what you're asking. Gmane uses a mail verification mechanism - they don't allow posting of any message until you confirm your email address ( for each group ). ( they send you a message after the first post, and if you reply then the post and all following posts will be allowed ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mozilla mail filters
Hi Pier, Is this a feed from gmane ? Does it use the same mail verification program? Do you plan to take the whole feed ( including non apache lists )? Costin Pier Fumagalli wrote: Pier Fumagalli [EMAIL PROTECTED] wrote: Vincent Massol [EMAIL PROTECTED] wrote: - how fresh are the messages in the newsgroup? It seems there is a few hours delay between emails and newsgroup. That makes it difficult to use newsgroup in replacement of emails, don't you think? Well, to put it that way, when I get them, they are on the newsgroup as well... Sometimes there might be some delay because ATM the news server is on my ADSL (and if I'm downloading something big, mail takes a while). There, I got this back in roughly 2 minutes... Not bad... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta member seeking ASF membership
+1 ! While at the moment I don't seek ASF membership, I think it would be excelent if more jakarta commiters who are and have been active in this community send mail to the pmc and ask those who are members for nomination. Costin Morgan Delagrange wrote: Hi all, [from a previous thread on a previous list] Morgan Delagrange wrote: I don't know if I've yet achieved the status of a long-term [committer] who have earned the right to set Apache-wide policies [...] However, there's no time like the present to find out. Roy Fielding has suggested that not enough Jakarta members seek membership in the ASF. Until recently, I was quite happy plugging along in my little Jakarta world, developing software and trusting the Apache world to continue onward as it has. However, recent events have shown me that my view may be too narrow. One specific example (sorry if you subscribe to the reorg list, as this is repetition of threads there): a top-level Apache project with the same name and similar scope as a Jakarta subproject can be proposed, discussed and approved (including a PMC) without ever being mentioned on a list to which I can subscribe. This week, a mailing list was formed to try to alleviate some of these communication deficiencies, but in the words of a former U.S. president, trust, yet verify. So my specific goal in seeking ASF membership is to look inside the black box. I already know that important decisions can be made that are hidden from the view of most committers. I'd like to know more about the process, and hopefully help to make these decisions more open and transparent to committers at large; at present a very small percentage of Jakarta members are actually ASF members. Likewise, I encourage other Jakarta committers to consider seeking ASF membership if they are also concerned about representation and the decision-making process. The Board seems very interested in increasing our numbers in the ASF membership, and I think we should take them up on this opportunity. Specifically, I'd like to ask a member of our PMC or any current ASF member to sponsor my membership., Unfortunately I will probably not be able to attend the next Foundation meeting, and so I'd also ask that my sponsor act as my proxy, if possible. If I understand this process correctly, if I am nominated, I fill out an application form and it's discussed on the private [EMAIL PROTECTED] mailing list until a decision spits out. I guess I won't be gaining any insight into the admission process at first. :) - Morgan = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- Costin -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Theft of authorship
I know the feeling... I don't think there is too much to do about it - the licence allows that, as long as they keep the Apache copyright. Costin --- Ceki Gülcü [EMAIL PROTECTED] wrote: Hi Jon, I am referring to otherwise honest people who choose to contribute their enhancements back to the project. They create new classes but in the process remove the names of previous authors. They do this in good-faith as otherwise they would not have contributed their code. I think it is a question of culture/custom. I do not think we have a document outlining authorship rules. Does anyone know one? Regards, Ceki At 11:51 07.06.2001 -0700, you wrote: on 6/7/01 11:42 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: This comes up from time to time and usually has me jump through the roof. Good willing contributors, take a piece of existing log4j code, modify or enhance it, but remove the previous author's names. They then post their code as if it was their own. Regardless of how much they modified the code, by removing the previous author's names they are committing theft. I find this very disturbing. What do others think? What can we do to combat this phenomenon? Regards, Ceki There is a difference between doing this accidentally and doing it on purpose. If it is determined that it is done on purpose and the people who did it refuse to follow the license, then the Jakarta PMC should be notified and we can sick the ASF Legal team on the problem. Note, this seems like it would be a last resort type of situation. The best is to try to at least discuss with the villains (jokingly said) first and make sure that it was not intentional. -jon -- Open source is not available to commercial companies. -Steve Balmer, CEO Microsoft http://www.suntimes.com/output/tech/cst-fin-micro01.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
