Re: Jakarta: Confederation or Single Project?
- Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Jakarta General List" <[EMAIL PROTECTED]>; "Harish Krishnaswamy" <[EMAIL PROTECTED]> Cc: "Jakarta General List" <[EMAIL PROTECTED]> Sent: Thursday, December 18, 2003 10:26 PM Subject: Re: Jakarta: Confederation or Single Project? > Quoting Harish Krishnaswamy <[EMAIL PROTECTED]>: > > > 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 > > > > These comments are going to be (like anyone's would be) colored by my own > personal experiences during the development of Jakarta -- including my > ignorance of a lot of the details in subprojects that I'm not an active > participant. But it should give you a little feel for the history of the > place. > > The gist of the creation of Jakarta was around three facts: > > * Apache wasn't an incorporated entity (this is about > four years ago now), but wanted to be -- and was > formally becoming the Apache Software Foundation. > > * Apache had a project to build a servlet container > (Apache JServ) at a website called "java.apache.org" > which created a trademark-use issue around "java". > (I was a committer on Apache JServ, which is how I > originally got involved in open source software.) > > * Sun wanted to contribute, and Apache wanted to accept, > the source code for the servlet and JSP implementation > called the "Java Servlet Development Kit", and later > published by Apache as Tomcat 3.0. > > Just as an item of slight historical interest, "Jakarta" was the name of the > conference room at Sun where a lot of the early discussions took place. > > An organizational framework to focus on developing "open source server side Java > stuff" was created to host these initiatives, and other related subprojects got > proposed and added to the mix. As the number of Jakarta committers scaled from > the original 10 or so to where we are today (hundreds), the original charter > has > become, umm, somewhat stretched. > > Ironically, it didn't take long at all for the scope of that original charter to > get exceeded, because one of the little nuggets of code that was included in > the > original Tomcat contribution was a pure-Java build tool (to replace "make") > called "Ant" ... > > As more and more subprojects were added, there were some inevitable cases of > overlapping scope, and overlapping implementations of the same ideas. One of > the best things we've done (IMHO) was purposely creating a subproject > (jakarta-commons) focused on making "small, focused, reusable" packages, and > encouraging the larger projects to use them. Not only has this been successful > within Jakarta -- there's been quite a lot of cross-fertilization among the web > app frameworks, for example -- it's also created a fairly rich library of > funcational packages that are widely used elsewhere. But one could really > argue whether something like Commons Digester (originally designed as an > easy-to-use tool to parse XML configuration files) really fit the Jakarta > charter. > > Over time, there have been more than a few, err, "voluminous" discussions about > how to scale up Jakarta from an organizational perspective, and whether the > fundamental organizing principle was still the correct one. Does a focus on > server side stuff exclude what could be some really interesting open source > projects? Does a focus on Java make sense when just across the website there > are things like xml.apache.org that are focused on a technology, not on an > implementation language? Does it make sense to have "community" type projects > that host individual software package projects at all? > > Coupled with these increasing concerns (at the ASF board level) about the > ability of any oversight group (a responsibility delegated to PMCs in the ASF > organizational structure), several original Jakarta subprojects (or even > sub-sub-projects in some cases) like Ant, Maven, and James decided to become > top level projects (TLPs) of their own -- this takes making a formal proposal > to the ASF Board that gets accepted, and the formation of a PMC for that > project. Those sorts of discussions continue to this day. > > Somewhat separately, but overlapping in time, it became clear that there needed > to be a way to incorporate new developer communities (and in some cases > existing codebases that were being contributed) into Apache. The developers > (if they weren't Apache committers already) needed to learn "the Apache way" to > do things. The code (if any) needed to be vetted for appropriate contributor > agreements to protect both the ASF and those that rely on our code. Thus, the > incubator project was created as a place for these things to happen. It is > also actively evolving. > > > To a large extent, the stresses that are felt as the ASF grows are actually a
Re: Confused with PMCs, TLPs, ASF and Power?
> Be aware of the > disclaimer at the top Nice disclaimer ;-) d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Harish Krishnaswamy wrote: How about Jakarta = "Java Development"? Then, they all seem in place, no? Henri Yandell wrote: Because it's wrong. XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. 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. Think of any large brand: McDonalds: Fast food restaurants. And accommodation. And a childrens charity. Nike: Sneakers (trainers). And sports clothing. And fashion clothing. And a sports team. And a college (American) football league. Virgin. Music label. And music shops. And hot air balloons. And an airline. And trains. And mobile 'phones, drinks, health clubs, Internet service provider, credit cards, finance and car rentals. Personally, I think the Jakarta brand has much much more to say about *how* the software is developed and *how* the community operates than *what* products are offered, *what* language it is written in and *what* languages can use the products. So perhaps the Jakarta tagline should be "...it's in the process. ...it's in the community". -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why you *want* to be on the PMC
On Dec 19, 2003, at 12:21 AM, Noel J. Bergman wrote: Henri Yandell wrote: If all the PMC's share the same website, who is responsible for the website as a global concept. For example, the need to do mirrors. If a Jakarta-Site PMC exists, all other PMCs [jakarta sub-project based] are accepting the Jakarta Site PMC's oversight over their websites. How do you think the Jakarta site works already? The site2 module is just the "core" Jakarta site. All of the projects already have their own sites in their own CVS, which are then checked out under the /www/jakarta.apache.org/$project. Nothing would have to change, unless a project *wanted* a new domain, from what I can see. Am I missing your point? I'm just not seeing the problem. The Jakarta PMC, as the group responsible for oversight of Jakarta, is responsible also for all content on the website. And I couldn't imagine projects leaving jakarta not wanting their own website. geir --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
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. 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. 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. 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? In my experience, if you make a significant contribution to any open source codebase anywhere, its community will welcome you with open arms. We don't need hostnames to create communities. People create their own communities and forge their own relationships, by the simple virtue of their contributions. 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! The real, underlying issue with Jakarta is that most of our products are *not* about Java. They are about a feature set. Java was just a convenient implementation language, but most of our products could be implemented in other languages and made available to a broader community. In fact, many have, but since they are not Java implementations, we have multiple communities around a product instead of one. A language-centric project like Jakarta doesn't create community, it dilutes it. But I would not say that Jakarta is broken. I'd say Jakarta is finally starting to work. The proof that Jakarta is working is that products are finally growing up and becoming projects. Every worthy parent's goal is self-sustaining children. The Foundation, like a good parent, has always tried to build self-sustaining projects -- projects that can outlive their creators. I'm happy that some of these projects were born at Jakarta and became great enough to join our top-level peers. So, why are Ant, Maven, Logging, Slide, et al, graduating to top-level Apache projects: because they can :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
On Dec 19, 2003, at 8:01 AM, 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. Not to Java people. I agree w/ you that it should be, but "Apache Jakarta" serves just as well, just as "Apache Httpd" is a strong brand too :) 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. 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. Jakarta is also a community - while it may also be a "romantic notion", it is a fact. Denying that fact serves well the high-minded notion of "for the Foundation", but ignores the reality. The ASF has seen the incredible growth of codebase, community and thus opportunity for participation in the projects like Jakarta, XML, WebServices, etc, all of which are larger umpbrella-like entities where like minded people can come together and work on whatever "scratches their itch" near and with others that also have the same interests. Preserving those fostering communities is a "romantic notion" worth working for, and not at adds with the ASF or it's governance requirements. It generates an opportunity for new ideas and collaborations to take hold, and a place go grow and live until the project wants to be a TLP. Or doesn't. :) geir P.S. And before you say "Incubator Project", the Incubator is by design not intended to be such an entity, but rather a mechanism to ensure health and accounting of IP and community of incoming codebases and projects, the protection of the ASF. -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
Andrew, The big difference between Geir and you, is that Geir is actually trying to give feedback and explain the situation on what's going on. The only messages I keep reading from you are protests against private lists and that they should be public and for the rest nothing at all constructive. After a year watching your posts I have come to the conclusion that you probably still don't get it : you are the problem. You are part of that private list and have therefore the same responsibility as the other PMC members. If you think as a PMC member (you are that according to the jakarta website) that something should be in the open, just do it, instead of just saying that everything is decided in private without saying what is private.(that is even WORSE than keeping it private!) I think you are way out of line here blaming others, start looking at yourself for once! Hope to hear some constructive things from you in the future.. I don't expect a response from you, since you said you would never want to have anything to do with me, so I respect that. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
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. -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > Reply-To: "Jakarta General List" <[EMAIL PROTECTED]> > Date: Thu, 18 Dec 2003 22:26:44 -0800 > To: Jakarta General List <[EMAIL PROTECTED]>, Harish Krishnaswamy > <[EMAIL PROTECTED]> > Cc: Jakarta General List <[EMAIL PROTECTED]> > Subject: Re: Jakarta: Confederation or Single Project? > > Quoting Harish Krishnaswamy <[EMAIL PROTECTED]>: > >> 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 >> > > These comments are going to be (like anyone's would be) colored by my own > personal experiences during the development of Jakarta -- including my > ignorance of a lot of the details in subprojects that I'm not an active > participant. But it should give you a little feel for the history of the > place. > > The gist of the creation of Jakarta was around three facts: > > * Apache wasn't an incorporated entity (this is about > four years ago now), but wanted to be -- and was > formally becoming the Apache Software Foundation. > > * Apache had a project to build a servlet container > (Apache JServ) at a website called "java.apache.org" > which created a trademark-use issue around "java". > (I was a committer on Apache JServ, which is how I > originally got involved in open source software.) > > * Sun wanted to contribute, and Apache wanted to accept, > the source code for the servlet and JSP implementation > called the "Java Servlet Development Kit", and later > published by Apache as Tomcat 3.0. > > Just as an item of slight historical interest, "Jakarta" was the name of the > conference room at Sun where a lot of the early discussions took place. > > An organizational framework to focus on developing "open source server side > Java > stuff" was created to host these initiatives, and other related subprojects > got > proposed and added to the mix. As the number of Jakarta committers scaled > from > the original 10 or so to where we are today (hundreds), the original charter > has > become, umm, somewhat stretched. > > Ironically, it didn't take long at all for the scope of that original charter > to > get exceeded, because one of the little nuggets of code that was included in > the > original Tomcat contribution was a pure-Java build tool (to replace "make") > called "Ant" ... > > As more and more subprojects were added, there were some inevitable cases of > overlapping scope, and overlapping implementations of the same ideas. One of > the best things we've done (IMHO) was purposely creating a subproject > (jakarta-commons) focused on making "small, focused, reusable" packages, and > encouraging the larger projects to use them. Not only has this been > successful > within Jakarta -- there's been quite a lot of cross-fertilization among the > web > app frameworks, for example -- it's also created a fairly rich library of > funcational packages that are widely used elsewhere. But one could really > argue whether something like Commons Digester (originally designed as an > easy-to-use tool to parse XML configuration files) really fit the Jakarta > charter. > > Over time, there have been more than a few, err, "voluminous" discussions > about > how to scale up Jakarta from an organizational perspective, and whether the > fundamental organizing principle was still the correct one. Does a focus on > server side stuff exclude what could be some really interesting open source > projects? Does a focus on Java make sense when just across the website there > are things like xml.apache.org that are focused on a technology, not on an > implementation language? Does it make sense to have "community" type projects > that host individual software package projects at all? > > Coupled with these increasing concerns (at the ASF board level) about the > ability of any oversight group (a responsibility delega
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. The relative brand strengths aren't important to this discussion (I think we will have to agree to disagree in any case). I was simply attempting to demonstrate two points: * a brand can unify products that otherwise would have no business being together * a brand can be used to give a concrete definition of otherwise abstract, ill-defined or hard-to-grasp concepts 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. [snip] I go where my community lives; and my community is centered on a codebase, not a hostname. [snip] 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? To me, there is a difference between the Jakarta community and the Apache community. I think that the Jakarta community have a slightly different set of values than the wider Apache community. The values aren't wildly different, but they are different none the less. I think that this difference is most noticable in the discussions on lists like this. Now I'm not entirely sure I explicitly know both sets of values. In part this is because there is a difference between what the community claims as its values and how the community acts and in part because many of the values that the Jakarta community claims aren't written down. Certainly, the Jakarta community tend to go about their business in a slightly different way to the wider Apache community. Sometimes, the Jakarta way seems to work better or seems to be leading the way (for instance near-total transparency and openness, even when in means "airing your dirty laundry", or commons and commons-sandbox) and sometimes the Jakarta way demonstrates that it hasn't learned the lessons that the wider Apache community learned the hard way (such as keeping secret the rationale for blocking an admision to a board of people). Perhaps there is actually a "The Jakarta Way" that is similar to The Apache Way, that is not explicit right now. Such a term could encapsulate the Jakarta process, approach to the community and values. The real, underlying issue with Jakarta is that most of our products are *not* about Java. They are about a feature set. Java was just a convenient implementation language, but most of our products could be implemented in other languages and made available to a broader community. Agreed. My fear is that if we don't work now to really understand The Jakarta Way, install the good bits into The Apache Way and document the problems and solutions to the bad bits, ASF may loose something of real worth and may not ever truely recover. I am not sentimental about the Jakarta name, but I do recognise that Jakarta represents something unique that we are in danger of loosing. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Thanks Craig, this is elaborate, informative and puts the issue in my perspective. May be this should be put on the website too somewhere. Here are my inferences so far... ASF is a group of projects administered by the Apache board members. The board delegates certain responsibilities over to the PMCs of the individual projects while still maintaining the authority and management responsibilities. The PMC is responsible for a wholesome code and community of the project it oversees but does not have the authority to recognize new projects. Jakarta started out as a single project for a web container and has grown into a foundation of projects in itself without sufficient administration/organization. Here are my thoughts distilled from a lot others'... * I think the projects at ASF should be classified in some way (preferably by technology like we have now for xml, db etc.) into umbrella projects. All projects piled together at the top level would not convey very well. This is where Jakarta would need redefinition. Seems like the inital motivation, server side web development, is a good fit. And that would mean some reshuffling. * I think each umbrella project or each project within could have a PMC and each project should maintain a PMC membership of atleast 51% of its committers to sustain. * I think the website should match the organizational structure to avoid confusion. * I think the board should classify the newly adopted projects. Projects that churn out of existing projects should be brought back to the board for classification at the time of creating new CVS repositories. * Each umbrella could have a commons and a sandbox to share and play. * There could be a top level commons to house cross-umbrella components. It seems like what we now have is pretty much in good shape and only means that the following actions take place... * Reorganize Jakarta (and may be others??) * Enforce project level PMC membership Just my thoughts. Regards, Harish Craig R. McClanahan wrote: Quoting Harish Krishnaswamy <[EMAIL PROTECTED]>: 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 These comments are going to be (like anyone's would be) colored by my own personal experiences during the development of Jakarta -- including my ignorance of a lot of the details in subprojects that I'm not an active participant. But it should give you a little feel for the history of the place. The gist of the creation of Jakarta was around three facts: * Apache wasn't an incorporated entity (this is about four years ago now), but wanted to be -- and was formally becoming the Apache Software Foundation. * Apache had a project to build a servlet container (Apache JServ) at a website called "java.apache.org" which created a trademark-use issue around "java". (I was a committer on Apache JServ, which is how I originally got involved in open source software.) * Sun wanted to contribute, and Apache wanted to accept, the source code for the servlet and JSP implementation called the "Java Servlet Development Kit", and later published by Apache as Tomcat 3.0. Just as an item of slight historical interest, "Jakarta" was the name of the conference room at Sun where a lot of the early discussions took place. An organizational framework to focus on developing "open source server side Java stuff" was created to host these initiatives, and other related subprojects got proposed and added to the mix. As the number of Jakarta committers scaled from the original 10 or so to where we are today (hundreds), the original charter has become, umm, somewhat stretched. Ironically, it didn't take long at all for the scope of that original charter to get exceeded, because one of the little nuggets of code that was included in the original Tomcat contribution was a pure-Java build tool (to replace "make") called "Ant" ... As more and more subprojects were added, there were some inevitable cases of overlapping scope, and overlapping implementations of the same ideas. One of the best things we've done (IMHO) was purposely creating a subproject (jakarta-commons) focused on making "small, focused, reusable" packages, and encouraging the larger projects to use them. Not only has this been successful within Jakarta -- there's been quite a lot of cross-fertilization among the web app frameworks, for example -- it's also created a fairly rich library of funcational packages that are widely used elsewhere. But one could really argue whether something like Commons Digester (originally designed as an easy-to-use tool to parse XML configuration files) really fit the Jakarta charter. Over time, there have been more than a few, err, "voluminous" discussions about how to scale up Jakarta from an organizational perspective, and whether the fundamental organizing principle was still the correct one. Do
Re: Jakarta: Confederation or Single Project?
Quoting Harish Krishnaswamy <[EMAIL PROTECTED]>: > Thanks Craig, this is elaborate, informative and puts the issue in my > perspective. May be this > should be put on the website too somewhere. > > Here are my inferences so far... > > > ASF is a group of projects administered by the Apache board members. The > board delegates certain > responsibilities over to the PMCs of the individual projects while still > maintaining the authority > and management responsibilities. The PMC is responsible for a wholesome code > and community of the > project it oversees but does not have the authority to recognize new > projects. > > Jakarta started out as a single project for a web container and has grown > into a foundation of > projects in itself without sufficient administration/organization. > > Waiting for the bureacracy to be created first is kind of antithetical to the way most open source developers think :-). > Here are my thoughts distilled from a lot others'... > > * I think the projects at ASF should be classified in some way (preferably by > technology like we > have now for xml, db etc.) into umbrella projects. All projects piled > together at the top level > would not convey very well. This is where Jakarta would need redefinition. > Seems like the inital > motivation, server side web development, is a good fit. And that would mean > some reshuffling. The problem with "graph shaped" (single inheritance) hierarchies is that sometimes a single project fits more than one place. For example, where do you put Cocoon? It's clearly a thing that fits into an "XML Technologies" sort of place. It's also a thing that clearly fits into a "server site technologies" sort of place. The answer that Cocoon chose (the right one, IMHO) was to be a separate TLP that is *linked* to both of those technology's web sites. But, the more fundamental principle is that the legal organization of the ASF need not have anything at all to do with how websites are organized and how projects are made visible. > * I think each umbrella project or each project within could have a PMC and > each project should > maintain a PMC membership of atleast 51% of its committers to sustain. That's pretty much the way that Jakarta works now (we've focused on expanding the PMC membership over the last year to ensure coverage from all the subprojects). But, as a Jakarta PMC member, it's still a daunting thought to be held responsible for oversight of all the code, and all the releases, across all of Jakarta. It's hard enough for me, for example, just to stay current on the three projects I watch and try to participate in (Commons, Struts, Tomcat). I'm pretty clueless about what the Tapestry folks are doing, yet *I* need to approve releases? Having Tapestry committers on the PMC helps, but isn't sufficient. > * I think the website should match the organizational structure to avoid > confusion. I don't agree. The website(s) should be focused around making it easy for users to find out what Apache projects might have products that are relevant to their needs. The internal project organization is an implementation detail. > * I think the board should classify the newly adopted projects. Projects that > churn out of existing > projects should be brought back to the board for classification at the time > of creating new CVS > repositories. > * Each umbrella could have a commons and a sandbox to share and play. > * There could be a top level commons to house cross-umbrella components. > > It seems like what we now have is pretty much in good shape and only means > that the following > actions take place... > > * Reorganize Jakarta (and may be others??) The interesting question is what Jakarta becomes after the subprojects that want to become TLPs do so. I suspect that keeping it as a brand is likely to be helpful, but the brand has been pretty muddled too (is it "Apache Struts" or "Jakarta Struts"? Depends on which book title you read :-), and the earlier perceptions that Jakarta had for high quality server side Java code is starting to slip. > * Enforce project level PMC membership > IMHO, it's just not good enough to satisfy the oversight requirements delegated to the PMCs by the ASF Board. > Just my thoughts. > > Regards, > Harish > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Harish Krishnaswamy wrote: ASF is a group of projects administered by the Apache board members. The board delegates certain responsibilities over to the PMCs of the individual projects while still maintaining the authority and management responsibilities. The PMC is responsible for a wholesome code and community of the project it oversees but does not have the authority to recognize new projects. I'd say it the other way around. The ASF is a collection of communities that create and maintain codebases. To obtain infrastructure support and some legal protection, these communities donate the copyright of its software and ownership of its brand to the Foundation. In order to provide legal protection and watchdog its copyright, the board assigns a vice president to oversee the project. A committee is also convened to assist the VP with oversight. Since the committee is formed by a resolution of the board, its members are eligible for legal protection in the event of a lawsuit. Also, since the committee is the only formal body created by the board, only the votes of committee members are considered "binding". In the normal course, most or all of the committers are also committee members. (Jakarta being an anomaly.) In most cases, the community's codebase is focussed on a single product, and so all the committee members and committers are "in tune" with what is happening with it. The ASF has also been exploring the idea of "umbrella" projects like Jakarta, XML, Database, and Web Services. At this time, there is no clear consensus of whether these umbrella projects can function as well as the traditional projects. A very subtle concept is that the ASF doesn't actually "own" the codebase. The codebase belongs to its community, and under the Apache License, that community can always "vote with its feet". Since it is the community that gives the software its value (by using and maintaining it), there is an Apache belief that the community is the true owner of the codebase. The ASF just owns the brand and yesterday's copyright. The board is *very* sensitive to the needs of its communities. Software versions come and go, but communities endure. -Ted. - 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: Just in case you're curious
On Thu, 18 Dec 2003 10:23:16 -0500 Harish Krishnaswamy <[EMAIL PROTECTED]> wrote: > > For the record I'm in favour of transacting business HERE. > > But I would like to respond by saying that as I understand it it is the > > source and the development of it which is open, not the organisation. > > As a committer I would like to know what's going on with the origanization. I can > understand certain > private conversations that involve legal implications, but anything else, I think, > should be out in > the open to do justice to the committers. It seems like there is some talk going on > about the > Jakarta banner in private that I have no clue about. I would appreciate the > knowledge sharing in > such metters. That's just as I see it. Discussions should definetly take place HERE. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 - 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]
cvs commit: jakarta-site2/xdocs/site newbie.xml
tetsuya 2003/12/19 16:45:54 Modified:docs/site newbie.html xdocs/site newbie.xml Log: Added more links to developers' resources Revision ChangesPath 1.45 +19 -0 jakarta-site2/docs/site/newbie.html Index: newbie.html === RCS file: /home/cvs/jakarta-site2/docs/site/newbie.html,v retrieving revision 1.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- newbie.html 14 Dec 2003 00:21:16 - 1.44 +++ newbie.html 20 Dec 2003 00:45:54 - 1.45 @@ -253,6 +253,9 @@ How do I setup my email account? + +Other Resources? + @@ -635,6 +638,22 @@ See the instruction described http://www.apache.org/dev/committers.html#mail";>here for more details. + + + + + + + + + + Other Resources? + + + + + +http://www.apache.org/foundation";>Apache Software Foundation Website and http://www.apache.org/dev/";>Developers Resources might give you more useful information. 1.11 +9 -0 jakarta-site2/xdocs/site/newbie.xml Index: newbie.xml === RCS file: /home/cvs/jakarta-site2/xdocs/site/newbie.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- newbie.xml14 Dec 2003 00:21:16 - 1.10 +++ newbie.xml20 Dec 2003 00:45:54 - 1.11 @@ -59,6 +59,9 @@ How do I setup my email account? + +Other Resources? + @@ -337,6 +340,12 @@ See the instruction described http://www.apache.org/dev/committers.html#mail";>here for more details. + + + + + +http://www.apache.org/foundation";>Apache Software Foundation Website and http://www.apache.org/dev/";>Developers Resources might give you more useful information. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-site2/xdocs/site elsewhere.xml
tetsuya 2003/12/19 16:54:54 Modified:docs index.html docs/site elsewhere.html xdocsindex.xml xdocs/site elsewhere.xml Log: 18 December 2003 - Apache Ant 1.6.0 Released ! Congratulations! Revision ChangesPath 1.350 +1 -1 jakarta-site2/docs/index.html Index: index.html === RCS file: /home/cvs/jakarta-site2/docs/index.html,v retrieving revision 1.349 retrieving revision 1.350 diff -u -r1.349 -r1.350 --- index.html12 Dec 2003 12:44:14 - 1.349 +++ index.html20 Dec 2003 00:54:53 - 1.350 @@ -249,11 +249,11 @@ Other news from Jakarta and Elsewhere +18 December 2003 - Apache Ant 1.6.0 Released 03 December 2003 - Xerces-C 2.4.0 is now available 01 December 2003 - Apache Axis C++ v1.0 (Beta) Released 21 November 2003- Xerces-J 2.6.0 Released 20 November 2003- Incubated-JaxMe 0.2 Released -14 November 2003 - Apache Cocoon 2.1.3 Released 1.105 +32 -1 jakarta-site2/docs/site/elsewhere.html Index: elsewhere.html === RCS file: /home/cvs/jakarta-site2/docs/site/elsewhere.html,v retrieving revision 1.104 retrieving revision 1.105 diff -u -r1.104 -r1.105 --- elsewhere.html12 Dec 2003 12:44:14 - 1.104 +++ elsewhere.html20 Dec 2003 00:54:54 - 1.105 @@ -195,7 +195,38 @@ - + +18 December 2003 - Apache Ant 1.6.0 Released + + +The Apache Ant Team and Apache Software Foundation are happy to announce that Apache Ant 1.6.0 is now available. + + +You can download the latest Ant from + +Binary Distribution: http://ant.apache.org/bindownload.cgi";>http://ant.apache.org/bindownload.cgi +Source Distribution: http://ant.apache.org/srcdownload.cgi";>http://ant.apache.org/srcdownload.cgi + + + +Thanks to all the people who have contributed to Ant, who have sent +critics, comments, patches, questions, ... +For the ones who have sent patches or bug reports which are not yet +processed, keep chiming in to remind us of your issues , hopefully we +will be able to solve them. + + +We have done our best to offer new features such as antlib, macrodef, +presetdef, ssh tasks, ... and to fix bugs. + + +A lot of luck with the use of ant 1.6.0. + + +For more information, take a glance at http://ant.apache.org/";>Apache Ant Website. Enjoy! + + + 03 December 2003 - Xerces-C 2.4.0 is now available 1.288 +1 -1 jakarta-site2/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-site2/xdocs/index.xml,v retrieving revision 1.287 retrieving revision 1.288 diff -u -r1.287 -r1.288 --- index.xml 12 Dec 2003 12:44:14 - 1.287 +++ index.xml 20 Dec 2003 00:54:54 - 1.288 @@ -56,11 +56,11 @@ Other news from Jakarta and Elsewhere +18 December 2003 - Apache Ant 1.6.0 Released 03 December 2003 - Xerces-C 2.4.0 is now available 01 December 2003 - Apache Axis C++ v1.0 (Beta) Released 21 November 2003- Xerces-J 2.6.0 Released 20 November 2003- Incubated-JaxMe 0.2 Released -14 November 2003 - Apache Cocoon 2.1.3 Released 1.68 +33 -0 jakarta-site2/xdocs/site/elsewhere.xml Index: elsewhere.xml === RCS file: /home/cvs/jakarta-site2/xdocs/site/elsewhere.xml,v retrieving revision 1.67 retrieving revision 1.68 diff -u -r1.67 -r1.68 --- elsewhere.xml 12 Dec 2003 12:44:14 - 1.67 +++ elsewhere.xml 20 Dec 2003 00:54:54 - 1.68 @@ -12,6 +12,39 @@ + +18 December 2003 - Apache Ant 1.6.0 Released + + +The Apache Ant Team and Apache Software Foundation are happy to announce that Apache Ant 1.6.0 is now available.
