Re: [VOTE] Move Jakarta to the Attic; close down Jakarta PMC
Is there anything left actually to put in the attic? Maybe just disband the PMC? Phil On Nov 10, 2011, at 10:01 AM, Henri Yandell bay...@apache.org wrote: A joint vote to retire Jakarta into the Attic and to ask the board to close down the PMC. [ ] +1 [ ] -1, because Hen - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: Release BSF 3.1 (based on RC3)
sebb wrote: On 19/06/2010, Phil Steitz p...@steitz.com wrote: sebb wrote: [Third time lucky?] Please review and vote on the BSF 3.1 release. The artifacts are available at: http://people.apache.org/~sebb/bsf-3.1-RC3/ The Maven artifacts are at: https://repository.apache.org/content/repositories/orgapachebsf-004/ The SVN tag is at: http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC3 This will be renamed following a successful vote. Keys are here: http://www.apache.org/dist/jakarta/bsf/KEYS Vote will remain open for at least 72 hours. [ ] +1 I support this release. [ ] -1 I am against releasing the packages (must include a reason). Thanks in advance! - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org Sigs and hashes are good. All else looks good; but I got this error when I tried mvn clean test from the source distro (JDK 1.6): [INFO] Unable to find resource 'org.apache.bsf:bsf-engines:jar:3.1' in repository central (http://repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-impl/1.2.2/axiom-impl-1.2.2.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve dependencies for one or more projects in the reactor. Reason: Missing: -- 1) org.apache.bsf:bsf-engines:jar:3.1 When I later did just mvn it seems to have downloaded / installed everything it needs, so mvn clean test subsequently succeeds. I don't know if this is a real problem or not. This seems to be a general problem with multi-module maven testing. The command: mvn package works OK, and performs tests, even if the jars have not been installed locally yet. However mvn test does not work unless you do a prior install. I think that is a bug (or at the very least a sub-optimal design feature) in Maven. Might be good to add something to the BUILDING doc to indicate what you have to do first. This does already say to start by running: mvn The default goal is install, so this will ensure that subsequent mvn test commands do succeed. Thanks, Sebb. +1 for the release. Phil Phil Phil - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: Release BSF 3.1 (based on RC3)
sebb wrote: [Third time lucky?] Please review and vote on the BSF 3.1 release. The artifacts are available at: http://people.apache.org/~sebb/bsf-3.1-RC3/ The Maven artifacts are at: https://repository.apache.org/content/repositories/orgapachebsf-004/ The SVN tag is at: http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC3 This will be renamed following a successful vote. Keys are here: http://www.apache.org/dist/jakarta/bsf/KEYS Vote will remain open for at least 72 hours. [ ] +1 I support this release. [ ] -1 I am against releasing the packages (must include a reason). Thanks in advance! - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org Sigs and hashes are good. All else looks good; but I got this error when I tried mvn clean test from the source distro (JDK 1.6): [INFO] Unable to find resource 'org.apache.bsf:bsf-engines:jar:3.1' in repository central (http://repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-impl/1.2.2/axiom-impl-1.2.2.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve dependencies for one or more projects in the reactor. Reason: Missing: -- 1) org.apache.bsf:bsf-engines:jar:3.1 When I later did just mvn it seems to have downloaded / installed everything it needs, so mvn clean test subsequently succeeds. I don't know if this is a real problem or not. Might be good to add something to the BUILDING doc to indicate what you have to do first. Phil Phil - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] JMeter 2.3.2RC3
On Thu, May 29, 2008 at 5:56 PM, sebb [EMAIL PROTECTED] wrote: On 30/05/2008, sebb [EMAIL PROTECTED] wrote: On 28/05/2008, Henri Yandell [EMAIL PROTECTED] wrote: MD5, PGP good. It's a bit odd that the binary version comes chock full of jars and the source version doesn't. When I run 'ant' in the source version I get: BUILD FAILED /Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/build.xml:925: /Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/lib/opt not found. I need to look at that. Fixed in SVN. If a build is attempted from just the source archive the output is: C:\ReleaseCheck\jakarta-jmeter-test ant Buildfile: build.xml _message_3rdParty: [echo] Cannot find all the required 3rd party libraries. [echo] If building from a release, you need both source and binary archives. I tried unpacking the binary archive and then building the sources, but even the binary tarball does not create or populate the opt directory that seems to be required by the source build. Phil
Re: [VOTE] JMeter 2.3.2RC6
sebb wrote: Trying again ... The licence issues reported by Henri have (I trust) been fixed. To rebuild or test JMeter, you need to unpack both the binary and source archives in the same directory structure. This is because the library files are not duplicated in the source archive. I unpacked both, but am still getting this: BUILD FAILED /home/phil/jmeter/jakarta-jmeter-2.3.2/build.xml:927: /home/phil/jmeter/jakarta-jmeter-2.3.2/lib/opt not found. The build succeeds (other than the test error mentioned in the README) if I mkdir opt from the /lib directory. Phil Note that there is a bug in Java on some Linux systems that manifests itself as the follow error when running the test cases or JMeter itself. [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.2RC6/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3.2RC6/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC6 Keys are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt also http://www.apache.org/dist/jakarta/jmeter/KEYS All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and create the release tag from the RC tag. Here's my: +1 S/// - 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: [VOTE] Commons moving to TLP
Stephen Colebourne wrote: This seems a little overplanned in my mind ;) Allow a little more evolution. - Commons goes TLP. - Rules for Commons TLP become clear (one mailing list, one PMC, anyone commits in any component, anyone votes/reviews any release, comfortable social group) - Then invite communities from Jakarta to join if they wish (once the rules and expectations are clear) Simple. And community-up not top-down. +1 Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Commons moving to TLP
+1 Phil Sadly a bit too late to make the next board meeting I suspect. However, here's a vote for Commons to officially request that it move to TLP. http://wiki.apache.org/jakarta-commons/TLPResolution Please add your name if you're a Commons developer and haven't added your name yet. [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Hen - 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: [VOTE] Petar Tahchiev as Jakarta Committer
+1 Phil Felipe Leme wrote: Hi all, I'd like to call a vote to have Petar Tahchiev as a Jakarta Committer. Petar currently works as software engineer in Bulgaria, but was a MSc student last year, when we proposed porting the Cactus build to Maven 2 as a GSOC (Google Summer of Code) project. Although the project didn't make it to the allotted ASF projects, Petar kept doing the (hard) work, despite my slowness to support him. Prior to participate on Cactus development, he made some contributions to Apache Ant and other ASF projects. He also has a blog at java.net (http://weblogs.java.net/blog/paranoiabla/). A couple of months ago, I failed (again :-() to setup a sandbox SVN branch at ASF for him to continue his work, so he ended up creating a separated repository on SourceForge where we could do some work in parallel. Now that code is ready to come back to the Jakarta codebase, and the proper legal measures has already been taken (see http://incubator.apache.org/ip-clearance/jakarta-cactus-tahchiev.html). Besides the technical aspect, I can tell from personal experience that he is a talented and enthusiastic developer, and will be a valuable contributor to the Cactus/Jakarta communities. So, here is my (PMC binding) +1 vote. -- Felipe - 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: Nightly builds docu?
Henri Yandell wrote: On 1/16/07, Ortwin Glück [EMAIL PROTECTED] wrote: Hi, Does anyone (Henry?) know what happened to http://www.apache.org/dev/nightly-builds.html ? It's referenced from http://www.apache.org/dev/ at the very bottom of the page. I'm looking for information how to get nightly builds done for HttpComponents. It probably never existed. When that page was created the links were made for pages that didn't exist to encourage people to write them - didn't work :) Nightly build wise... it's still an unorganized situation. In Commons we have some hand written scripts that are used on a zone (vmbuild) to build the code each night. Taglibs used to be built each night on Glenn's machine (I suspect that's not true anymore). We could expand the script for Commons to work from the Jakarta perspective and not the Commons one. +1 and would not be hard to do. Makes sense to do this for all Jakarta components that want nightlies and as long as the builds are reasonable in execution time, this should not be a problem. The current script supports Ant, Maven 1 and Maven 2. The script code is in svn at jakarta/commons/proper/commons-nightly/. The main script, commons_nigthly.sh gets svn upped on vmbuild by a crontab wrapper before executing each night, so if you just make changes to include a new build or build type into this script and config and check in the changes, the new component will be added. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml
Dennis Lundberg wrote: Phil Steitz wrote: Henri Yandell wrote: On Fri, 11 Aug 2006, Dennis Lundberg wrote: Phil Steitz wrote: Thanks, Dennis. That helps and I agree with your arguments for inheritence in genera;. But why a Jakarta parent? I'll leave that one for Henri to answer. Do I look like I know what I'm doing? :) The Jakarta pom is there because it seemed like a good idea to share things between Jakarta m2 projects and not just Commons ones - or at least to try and encourage that sharing. Though I had thought that the mailing lists in the parent would appear in the children and that's not happened. It didn't seem like it would be damaging to represent the current structure and Brett didn't run screaming when I asked him :) I'm not tied to it though - just throwing energy at the commons to m2 problems. Can someone less m2-newbie than me pls publish the jakarta and commons parents to the m2-snapshot-repo? The sandbox parent appears to be there, but the others are not and they have to be manually installed to get any commons m2 builds to work. That makes it pretty hard for the non-initiate to build the components (e.g. [pipeline]) that are dropping m1 poms. Done. I have deployed the poms jakarta, commons and commons-sandbox. Thanks, Dennis! Now I am confused, though, since we seem to have both commons-sandbox and commons-sandbox-parent and the sanbox m2 builds seem to be evenly split between them, though all (other than pipeline) are listed as modules of commons-sandbox. Are these for different purposes? Also, do we really want to have the individual components set up as modules? Still in learning mode here... Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml
Thanks, Dennis. That helps and I agree with your arguments for inheritence in genera;. But why a Jakarta parent? And can you answer the second question about addressing? I am -0 on doing anything that cements Jakarta into the namespace above commons artifacts. Sorry if this has been discussed and agreed and I just missed it. Phil From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Fri 8/11/2006 9:36 AM To: Jakarta General List Subject: Re: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml Phil Steitz wrote: Henri Yandell wrote: First few commit messages bounced on this btw, until I fixed that up. It's a maven2 Hen, Can you enlighten the rest of us as to what this is for and what, if any, implications it has on how we address maven2 artifacts originating in jakarta projects? Phil snip/ The purpose of having a parent pom is to reduce the amount of information you need to put in the pom of a specific project. It also makes sure that all projects us the *same* information for certain things. These things are put in the parent. An example of this is which plugins *all* projects must use. Each project can then add more plugins if they so desire. Now I know some of you are preparing to throw in arguments about how we tried to do this with Maven 1 and it failed. Before you do there is one crucial difference. In Maven 1 the parent had to reside somewhere within the same file system as your project. In Maven 2 the parent pom is published to a Maven repository. It is then downloaded like any other artifact by Maven automatically. So there will be no need to check out jakarta-build from svn and putting it in the exact correct location on your own machine. -- Dennis Lundberg - 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: testing.apache.org, take 2
Rahul Akolkar wrote: On 6/20/06, Phil Steitz [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 6/16/06, Felipe Leme [EMAIL PROTECTED] wrote: snip/ I think these statements are a good start for the next meeting's proposal - could someone write an wiki entry for it (or even update the current resolution)? I'm traveling until Sunday and my internet connection is pretty bad here, so it would be hard for me to do it... snap/ Thanks for putting it all together as a summary, I've put the closing statements from that email, verbatim, on a wiki page [1]. Its open to edits (I might make some minor edits myself in a day or two). This is good. Here are a few additional things that we might want to think about adding, assuming all are OK with these commitments. snip/ This (below) is generally in line with my expectations of how things should work, and aligned to what we've said previously in these threads, IMO. Ideally, there'd be a mechanism to get some feedback, even in your absence (thanks for volunteering though). -Rahul This list is designed to address some of the concerns that have been raised in the past about umbrella projects. Obviously, not all may agree with the points below, and even with these provisions, the board may not approve the Testing proposal. I just thought it would be a good idea to get these ideas out for discussion for this and the other umbrella-like things that we may be splitting Jakarta into. 1. The PMC members named in the proposal are signing up to provide oversight for the *entire project*, not just subprojects that they participate in. In fact, there are formally no subprojects, just products or code bases that are versioned / released separately. I would recommend that we avoid the use of the term project other than for the TLP itself and avoid subproject altogether. 2. As new components are incorporated, the PMC will grow and will always include the (the majority of) active committers working on each of the components. Ability to make decisions on behalf of the whole project will be considered when granting commit access. 3. A necessary condition for adoption of a codebase or creation of a new component will be commitment from a minimum of 3 PMC members (possibly existing ASF committers, joining with the codebase) agreeing to review / apply patches, review commits, serve as RM, etc. for the new component. 4. If one or more of the components, or the entire project, grows in complexity or community size this number intentionally left blank to the point where effective oversight / active involvement by the Testing PMC on all components is no longer possible, the project will be split (just as Jakarta is being split now, per this proposal). Note that this is a statement of intent, not an administrative mandate (i.e., the somewhat painful, consensus-driven process that we are following now in Jakarta is our *intention* to improve and maintain). 5. Inactive components, or components without a sufficient number of active PMC members, will be regularly archived. One more personal thing: I just learned that the board meeting has been postponed until next Tuesday. Unfortunately, I will not able to attend that day. Therefore, it would be great if one of the other members supporting this proposal could step up to attend. Phil With his permission, I am forwarding an excerpt from a recent post from Roy Fielding, in response to questions about a proposed Security TLP originating out of the XML project. The concerns he raises below all pretty much apply directly to Testing. Could be the right approach here is to limit it to Cactus + Jmeter, or even have them each TLP separtately. I think the key is really point 1. above as well as Roy's argument below about not claiming dominion over a topical area. Roy Fielding on 6/22: When a project owns a category, such as security, the participants think that they are responsible for all Apache products in that space. Meanwhile, what they are actually working on is a fairly small project that addresses the specific requirements of a given set of users, such as xml-security. People don't try to make products that are applicable to every possible consumer in a given category, and volunteers cannot oversee projects in which they do not actually participate. What is left is either a single project that rejects all new target audiences or an umbrella project that creates an artificial barrier to oversight. There is no way to broaden the perspective of a project -- people simply don't wake up one day and discover a need to be aware of everyone else's work in similar projects, and most people don't have the bandwidth to do so anyway. That is why each project has to be self-governed. When someone else comes along and says an obvious thing like XML is inherently non-secure, I want to work on a security project that demonstrates a better way of securing blah
Re: testing.apache.org, take 2
Rahul Akolkar wrote: On 6/16/06, Felipe Leme [EMAIL PROTECTED] wrote: snip/ I think these statements are a good start for the next meeting's proposal - could someone write an wiki entry for it (or even update the current resolution)? I'm traveling until Sunday and my internet connection is pretty bad here, so it would be hard for me to do it... snap/ Thanks for putting it all together as a summary, I've put the closing statements from that email, verbatim, on a wiki page [1]. Its open to edits (I might make some minor edits myself in a day or two). This is good. Here are a few additional things that we might want to think about adding, assuming all are OK with these commitments. This list is designed to address some of the concerns that have been raised in the past about umbrella projects. Obviously, not all may agree with the points below, and even with these provisions, the board may not approve the Testing proposal. I just thought it would be a good idea to get these ideas out for discussion for this and the other umbrella-like things that we may be splitting Jakarta into. 1. The PMC members named in the proposal are signing up to provide oversight for the *entire project*, not just subprojects that they participate in. In fact, there are formally no subprojects, just products or code bases that are versioned / released separately. I would recommend that we avoid the use of the term project other than for the TLP itself and avoid subproject altogether. 2. As new components are incorporated, the PMC will grow and will always include the (the majority of) active committers working on each of the components. Ability to make decisions on behalf of the whole project will be considered when granting commit access. 3. A necessary condition for adoption of a codebase or creation of a new component will be commitment from a minimum of 3 PMC members (possibly existing ASF committers, joining with the codebase) agreeing to review / apply patches, review commits, serve as RM, etc. for the new component. 4. If one or more of the components, or the entire project, grows in complexity or community size this number intentionally left blank to the point where effective oversight / active involvement by the Testing PMC on all components is no longer possible, the project will be split (just as Jakarta is being split now, per this proposal). Note that this is a statement of intent, not an administrative mandate (i.e., the somewhat painful, consensus-driven process that we are following now in Jakarta is our *intention* to improve and maintain). 5. Inactive components, or components without a sufficient number of active PMC members, will be regularly archived. One more personal thing: I just learned that the board meeting has been postponed until next Tuesday. Unfortunately, I will not able to attend that day. Therefore, it would be great if one of the other members supporting this proposal could step up to attend. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org
Rahul Akolkar wrote: On 6/6/06, Felipe Leme [EMAIL PROTECTED] wrote: snip/ So, answering your question, yes, the project is supposed to support libraries from another languages. In fact, the existence of such libraries is an argument for the TLP creation; besides the existing Cactus and JMeter, we have at least 3 sub-projects contenders (the 2 you mentioned and one for testing HTML pages), 4 if we count DbUnit (although this one will take more time due to the licenses incompatibility). snap/ Yup, there clearly is developer/community interest towards the formation of this project. Plus, there is a chance to rejuvenate some existing projects by sheer proximity to newer projects with active developers (amongst other things). Per the umbrella concern, the question then becomes what -- if any -- are the mitigating factors that can address such a concern with regards to this proposal. Based on Hen's email, seems like the ball is still in the board's court -- as we wait for the next meeting -- so maybe its premature to discuss if we should be trying to address those comments yet? I would also like to understand exactly what the problem is and what mitigating steps may be possible. In particular, I would very much appreciate a definition of umbrella that allows Geronimo, Logging, Jakarta Commons, DB, XML, Web Services and Struts, but somehow disallows Testing. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
Martin Cooper wrote: snip/ I think this whole thing is putting the cart before the horse. You're in the process of destroying Commons, not just dismantling it, and for no good reason that I can see. The people involved with Digester should be the ones to initiate a discussion about whether or not they want to take Digester elsewhere. As it is, this is coming across more like why don't you guys go away, somewhere far away, 'cos we think that's a good idea. Stephen's proposal for Jakarta Language Components came from inside that grouping. So should any other proposals for groupings or departures. With respect to departures in particular, there is a serious potential for losing community. For example, I keep tabs on a bunch of different Commons components, primarily because all of the discussions happen on communal lists. If Digester and DbUtils, for example, go to some other community where they also share lists, I am very unlikely to sign up for those lists just to keep tabs on those components. Maybe the developers will move, but how much of the community will go with them? I agree strongly with the points above. I am +1 for jlc but -1 for engineered dissolution of j-c. The key point is that movement needs to be driven by people who want to move. Consider these two specific examples: [naming] - we decided on ontological grounds to move this to Directory some time ago. We were never able to build a community around it there, the Directory community had no interest in it, and it has gone nowhere. Of course, it may have gone nowhere in j-c as well, and its stalling could all just be lack of vision / ability to get tomcat to go along, but I can't help thinking that it would have done better off staying in j-c. [dbcp] - suppose some grand scheme had already moved it to DB. Would volunteers there now be stepping up to maintain it now? If the move to DB was initiated by community members who really wanted to drive it, then the answer would likely be yes. That is the key point. There have been *many* examples over the years of j-c community members stepping up to contribute to components that they were not involved in when they started at the commons. There is also tremendous value in the collective oversight, both technical and community / legal, that happens in j-c. We should think very carefully before dissolving that community. Phil Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Stephen Colebourne wrote: Roland Weber wrote: Hello, other 1-word suggestions would be great. since they're language components, you can call them Syllables :-) I understand the desire for 'fancy' names, but it misses the point unfortunately. This is merely a grouping a several *Jakarta* components. A fancy name should be thought of as implying TLP status. +1 for the idea and also for the bland name - one of the things that I personally like about the I guess soon-to-be-defunct (sob, groan, choke j-c charter. Thanks, Stephen for pushing this forward. On the mailing list issue, I assume you mean we would have a jlc-dev, and jlc-user as well as the Jakarta-dev that you mention. Also, while this is technically [OT] here and probably deserves its own thread on j-c-dev, I would like to see [id] adopted as part of the formation of jlc - i.e., let it graduate into the new entity. Phil Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
Thomas Dudziak wrote: On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Thomas Dudziak wrote: Could you elaborate a bit on what the physical / visual-to-users differences to the current commons, well, Jakarta sub-project will be ? Will this be a new Jakarta sub-project (and the other commons components will remain in the current commons one) ? I've been trying to dodge this question. Why? Because I want to encourage other groupings (especially from commons) to self-select. If I make a proposal, then it will be an imposition. My hope is that in a few months we will have a mentality of working on *Jakarta* components, not working on commons (or any other) components. To achieve this will require other groupings. Note: I suspect that some Jakarta sub-projects, perhaps POI, Turbine and Velocity, may have real issues with this whole grouping philosophy. My answer is to *not* force communities that are truly content with the status quo to change. Each grouping will have: - a bland name (Jakarta Xxx Components) - an identity (how and why does the group exist) - sufficient size (to be active not inactive) - mailing lists (one ML for all Jakarta doesn't work) - SHARE COMMON ISSUES on a shared ML, [EMAIL PROTECTED] What I will say is that its too early to worry about website issues. For now, all we need to know is that there will be a link somewhere to each component, and probably a single page describing each group. Pages such as release procedures etc are Jakarta-scoped and discussed on [EMAIL PROTECTED] I understand this, but I wonder whether this move will have an immediate negative effect on the other Jakarta components in terms of developer attention both to the projects and to the users. As you say, probably not so much for the direct Jakarta sub-projects like Velocity, but for the other commons components. This is a good question and the one that has always given me pause when thinking about breaking up j-c. My expectation, though, is that like me personally, many of the people that will be active in jlc will also remain active in other components. The benefit will be for new contributors or those who want to just focus on the jlc components. The does it make sense as an extension to JSE? scoping criteria is also a powerful means of focussing effort for this group. As a side note, perhaps this is an opportunity to evaluate if there are better homes for some of the components ? E.g. betwixt/digester/jxpath could benefit from going to XML commons, dbcp and dbutils from going to DB etc. ? Definitely, but I think it is best to first get jlc set up and then let these discussions happen independently. Changes should be driven by the people in the communities who want to make them. Phil cheers, Tom - 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: Notice of intent.... #2
Henri Yandell wrote: As a second email in the Notice of intent series; here's what I think being a Jakarta component will be like in the future. * Jakarta is a collection of components. Hopefully all sitting at the same level. ie) a big bag of things. How are you defining component? Something reusable? Something you build applications with? Something like a commons component? If that is the case, then Jmeter, Cactus, Velocity et al would have to go TLP. Is that part of the plan? * Groups exist. These are categorically not subprojects, but a way to allow for slicing of the website etc. Some groups may have their own mail list; thus the importance of making sure they don't become subprojects. An important rule will probably be that they must do votes on the main list. Hopefully we can keep it at a point where the groups are really just there to refine the flow of mail, not to separate it. HttpComponents is an example of this (though not a good one as most of its components came from HttpClient). WebComponents (formerly hoped to be known as Silk) is another example. Commons would be groupalized out. Not sure I understand exactly what you mean here, but if it means breaking commons up - even the list - I think we should think very carefully about that. From what may be a selfish perspective - and which I will back off from if the rest of the community feels otherwise - I think getting feedback from the full group of commons committers and voluneers *really* helps those of us who work on commons components. I am afraid that if we break up the dev list and we don't all just agree to subscribe to all of the sublists (really defeating the purpose), we will both have a harder time building community around components and we will lose some valuable feedback. We will also have less collective energy to apply to things like the site, how we think about versioning and releases, etc. We are developing a pretty good body of collective experience developing small java components and I think that if we split up now we may be losing something. Hopefully. Groupings are not vague names - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The idea with that being that boring grouping names are intentionally dull, no subcommunity identification. +1 - as we at least used to state in the commons charter ;-) * No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI. +1 * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Not sure about this one. I am OK with kicking off the nomination more or less automatically, but would prefer that it be a postive vote. * Application of Commons thinking. Not entirely sure on this one as I think we've overcomplicated things in Commons a bit; but things like a common build system, common site system etc. * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the same rules as it has currently. Probably a separate mailing list. I agree with Martin's comment on this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project (fwd)
Henri Yandell wrote: An FYI. Please kick me if I'm going too far with these ideas; I get the feeling I have a general +0, but hard to tell sometimes. See interspersed. I am not quite to the + point yet, but probably either just missing some concepts / principles or interested in understanding better what the alternatives are. Hen -- Forwarded message -- Date: Tue, 27 Dec 2005 11:42:47 -0500 (EST) From: Henri Yandell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: general@incubator.apache.org Subject: Re: Starting a java specs project One idea was to collate them as a part of Jakarta. My aim for Jakarta is to either promote subprojects to TLP or flatten them into Jakarta Commons, The risk there is j-c becoming the new umbrella. We are also having enough trouble scaling j-c now. leading to a non-umbrella Jakarta It would be great if we could get a consensus on what an umbrella is and what is bad about it. I don't want to open too many cans of worms here; but not all of us were around for the good old bad old days of Jakarta. It seems to me that all of the following could now be considered umbrellas in some sense, but we (apache) seem to be collectively OK with them: Geronimo Web Services XML Struts DB Logging Portals But somehow Jakarta is too big. If you look at all of the code now coming into Geronimo with the incubations in progress, it will be larger than Jakarta currently is soon. So why exactly do we need to either mash, e.g. Hivemind into Commons or move it to TLP? If the answer is PMC oversight then why doesn't that apply to the projects above as well? We have made a lot of progress - mostly thanks to you, Hen - getting adequate PMC representation from all Jakarta projects, so I don't see that as such a big concern any more. So what problem exactly are we trying to solve by pushing things out or mashing them into Commons? I don't mean to be argumentative here, I just want to understand clearly what the goal is and what our acceptable options are. It would be great to have some principles on what kinds of aggregates (euphemism for umbrellas ;-) are OK and what kinds are not. Based on these principles, we might decide to divide Jakarta differently, creating some smaller aggregates rather than one big one (j-c) and a string of small TLPs. (I know, you didn't think you'd see it in your lifetime). This new Jakarta would have the potential to serve two roles: 1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED] 2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons] While j-c might have begun as 2), this is no longer the whole story, or even the main story any more. Storing the spec source there would be good for everyone I think; it would help bring people to Jakarta to share code and conversation, and the Commons community would make good stewards for the code if the various owners departed. We already have too much orphaned code in j-c, IMHO. The advantage of bringing this stuff to j-c would be bringing in some more active and engaged committers. This I am sure we would all welcome. Orphaned code we would not. Maintaining this code will require some specialized expertise most likely concentrated in projects like Geronimo, Tomcat, etc. If committers from these projects are interested and willing to sign up to actively support the code in j-c (including responding to user questions), I am sure we will be happy to have them join us. I would be hesitant to volunteer the j-c community, however, as a support mechanism without ongoing active involvement from the apache projects using the specs, though. Some other pluses are that it would help be a part of an attempt to rejuvenate Jakarta in 2006 (as a kind of federation) and that non-JCP specs could be stored there too. Not trying to intrude on the JCP stuff though, so I can see if it's preferred to keep things under a strictly JCP-oriented environment. Hen On Tue, 27 Dec 2005, Alan D. Cabrera wrote: There has been some discussion on creating a Java specs project which would hold all the specs jars from the various JSRs as well as other standards, e.g. CORBA. Often, there are many duplicate copies of the source code for the same JSR floating around in different Apache projects. It would be a great idea to move them all into one project. This idea, so far, has been met with much enthusiasm. How do we get this started? Regards, Alan - 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]
jakarta future WAS: Re: Starting a java specs project (fwd)
Henri Yandell wrote: snip/ It would be great if we could get a consensus on what an umbrella is and An umbrella is a joining of disjoint communities under a common TLP. A non-umbrella is one in which the whole project is a part of the same community. Nice definition. Thanks. snip/ The biggest problem with Jakarta currently is that we've become increasingly disjoint. In many ways we are less healthy than we were 4 years ago. We have less projects, but much less in the way of intersection between communities. We've replaced a 7 person sub-board with a single chair [though there is now quite a clear direction for that single chair]. Thanks again. So the real problem is disjointness. It seems then that we have three logical alternatives: 0) Full disintegration - all projects (incl j-c) become TLPs or die and Jakarta effectively dies as a concept. 1) Commons or bust - lump small components (e.g. BCEL, ORO) into j-c and move the others (e.g. Tapestry, Jmeter, Cactus) to TLP. Keep jakarta-general around and the Jakarta site for general Java community-building across apache. 2) Re-aggregate - divide Jakarta up into a small number of cohesive aggregates. Its not clear to me how this would work or if this kind of encouraged merging is a good idea; but it is logically the same sort of thing that you are hinting at in 1). 0) seems a shame from the Java community and Jakarta brand (whatever that means) standpoint; but may be the most reasonable thing to do. My concern with 1) is that j-c is already having trouble scaling and I am not so sure that once things are merged in (or out) there is anything substantial left for Jakarta to be (i.e., I am having a hard time seeing the real practical difference between 0) and 1)). I have to confess to having no idea how to do 2), but maybe others in the community do - ideally people working on projects that might want to aggregrate. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Missing source files
Yes, and (thanks to Rahul), Step 12 of the commons release instructions http://jakarta.apache.org/commons/releases/release.html has been updated to reflect the change. One more note that I am about to add is that the Ant build now used to gen the Jakarta site requires JDK 1.5, so make sure that ant is using a 1.5 JDK and check html diffs locally before committing. -Phil Rahul Akolkar wrote: On 12/23/05, Martin Cooper [EMAIL PROTECTED] wrote: I just went to add the Commons FileUpload 1.1 release to the Jakarta site, and discovered that at least two files are missing from the source repo. The news files for Q3 and Q4 of this year are present in the repo only as HTML files; the corresponding XML source files are missing. This is not good, to say the least. Does anyone have any insight as to how this happened? Does anyone have the source files that they could add back? I'm not about to start hacking the HTML files to add the FileUpload release... snip/ Martin, IIUC, the site build has changed a bit in that regard. The news items now go into the news.xml file in the top level site directory, and the build will generate the Q3/Q4 HTML files out of there. Ofcourse, downloads.xml needs to be updated as before. -Rahul -- Martin Cooper - 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]
[Annoucement] Commons Math 1.1 Released
The Jakarta Commons Math team is pleased to announce the release of Commons Math 1.1. Commons Math is a library of lightweight, self-contained mathematics and statistics components. For more information, see the Commons Math web site: http://jakarta.apache.org/commons/math/. The new release contains bug fixes and enhancements. All API changes are binary compatible with version 1.0. The enhancements include some new probability distributions, a Fraction class, new matrix and numerical utilities, and a PRNG pluggability framework making it possible to replace the JDK-supplied random number generator in commons-math (and elsewhere) with alternative PRNG implementations. A full list of changes since the 1.0 release can be found in the change log at http://jakarta.apache.org/commons/math/changes-report.html. Commons Math is available in either binary or source form from the Commons Math downloads page on the Apache mirrors: http://jakarta.apache.org/site/downloads/downloads_commons-math.cgi. The commons-math 1.1 release jar has also been deployed to the Apache Maven repository: http://www.apache.org/dist/java-repository/ and the Maven main repository: http://www.ibiblio.org/maven/. Please remember to verify the signatures of the files you download using the keys available on the download page. Jakarta Commons welcomes community participation and contributions from all interested parties. User feedback or questions related to Commons Math should be directed to the commons-user mailing list. Development-related topics are discussed on the commons-dev list. See the Commons mailing list page http://jakarta.apache.org/commons/math/mail-lists.html for instructions on how to subscribe to or view the archives of these lists. Please start the subject line of math-related posts to either of these lists with [math]. To submit patches or bug reports, follow the directions on this page: http://jakarta.apache.org/commons/math/issue-tracking.html Thanks in advance for your feedback! -The Commons Math Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multidoc-jnr - opinions?
Henri Yandell wrote: On Wed, 24 Aug 2005, Henning Schmiedehausen wrote: Hi, I toyed with similar ideas for a long time (I even had once an intern whip something up), however, there are a number of drawbacks: - different versions. The osjava variant tries to get this right by allowing the user to choose the versions. - inter-project links. Phils' variant builds everything in one big javadoc (don't do that. IMHO). So links beween projects are resolved correctly. You might even toss in links to Suns' official API docs for java.* and sun.* packages Once the versions are in official locations, each project can set their linking (least at osjava that's my plan). So links will work, but it won't all be in one big centrally built javadoc. Nicest would be to do this in maven.xml; have it automatically know the structure of the local javadoc tree and link the dependencies in. Easiest is to just hack each one into the project.properties. More on this when I get put another burst of energy into it. Also as the jar files are there, I think I can do something very cool with clirr :) I got the single big javadoc thing to work using maven without having to reference any of the projects directly (other than attributes, which has its sources in a non-standard place). The packages come out sorted in reactor order, though and due to general lack of enthusiasm for this approach, I did not spend any time trying to get jelly's util:sort to work to fix this. The maven.xml linked below contains some things that may be useful for the aggregation approach - collecting dependencies and javadoc links from the subprojects. http://people.apache.org/psteitz/apidocs/maven.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multidoc-jnr - opinions?
Sorry, should be http://people.apache.org/~psteitz/apidocs/maven.xml -Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multidoc-jnr - opinions?
Henri Yandell wrote: Prototype of what I want to do javadoc-wise for Jakarta :) http://dist.osjava.org/releases/multidoc-jnr/ (click on something as long as it's not Payload 0.3 or 0.4; seems my distributions are lacking javadoc there). Any opinions? I like the idea of doing this and being able to easily find javadoc for all release versions. It might be more convenient and maybe less confusing to have the release versions on the front page, though, so you could click on the release you are looking for. I have been playing with something similar for commons using ant. Here is an example built from current svn trunks: http://people.apache.org/~psteitz/apidocs/ I was thinking we could add a link on the commons site to current combined api docs and also latest release with the titles changed to include the release nunmbers. To keep the current content up to date, we could in theory add the generating ant script to the nightly build. This could be a slight pain to maintain, however, and because javadoc likes to do everything in memory, it is a pig to run. The script is here: http://people.apache.org/~psteitz/apidocs/build.xml Maybe its just me, but I like being able to browse all of the packages in one place. Phil -- Forwarded message -- Date: Sat, 20 Aug 2005 03:07:46 -0400 (EDT) From: Henri Yandell [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Osjava-users] Multidoc-jnr - opinions? Multidoc was an idea I had to generate a project-wide documentation site based on links to parts of each individual project (javadoc, xref, jcoverage etc). http://multidoc.osjava.org/. It works, but has complexity (has to scrape the parts of the projects to build its front pages). Multidoc-jnr is a simpler idea, with a much simpler implementation (http://svn.osjava.org/svn/osjava/trunk/multidoc-jnr/) that does much the same thing for released javadoc. Take a look: http://dist.osjava.org/releases/multidoc-jnr/ Hen - 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: Jakarta - Cleaning house
Brett Porter wrote: On 8/10/05, Henri Yandell [EMAIL PROTECTED] wrote: Promoting Commons Sandbox to SLP as 'Jakarta Sandbox'. + All Jakarta committers given access, central management of the sandbox + concepts as opposed to individual SLP sandboxes (Taglibs, Commons, + Turbine probably has things which could have gone in a sandbox). I'd be interested to know how this works - I'm not sure unification brings much to each of them, but it would allow a bit more oversight by Jakarta as a whole as to each things health. I am -0 on this, meaning I need to understand more what exactly it will accomplish and I have a couple of concerns. First I am worried that for j-c-s in particular, separation from j-c will make it harder for j-c-s projects to gain critical mass and graduate to commons proper. Second, removed from a parent SLC, a sandbox becomes a tricky thing to provide effective overight for. The mentor and ppmc roles in the Incubator are there for a reason. I would actually be more concerned about oversight in an aggregated sandbox. If we can implement the cleanup policies that we have been discussing on commons-dev, I think the j-c sandbox should continue to work fine as it is and in fact be a model for the other SLPs, each overseeing its own if desired. As I said, I need to understand better what problem we are trying to solve here. Deletion of all CVS/SVN karma (and subsequent re-addition upon request). + Clean up the very large lists of committers we have in each SLP. + Later the jakarta unix group can be sync'd to the SVN jakarta list. + Should spur a large-scale nomination of new PMC members. To save a bit of hassle I think you'll want to start by re-adding anyone who committed to that project in the last 90 days, otherwise that's a lot of requests :) Yes, definitely. Here again, not sure exactly what problem we are trying to solve. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r224411 snip/
Rahul Akolkar wrote: P.S.-What list do I subscribe to in order to receive the jakarta site svn commit messages? site-cvs@jakarta.apache.org Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
robert burrell donkin wrote: there doesn't see any enthusiasm for those new ideas and no objections to phil's draft. i think we should go ahead and make the changes suggested by phil. I went ahead and updated, making some small changes to (hopefully) address the points above. I marked the items to be replaced as DELETED and added the replacement items at the end. Given that the discussion has referenced item numbers, I did not want to mess up the numbering. We can reorder as appropriate when the music stops. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop 8
+1 to drop this Phil robert burrell donkin wrote: 8. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. doesn't seem very relevant. i think that it'd be simpler just to drop it. here's my +1 - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - 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: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
robert burrell donkin wrote: snip/ Agreed. After a little more discussion, we should rewrite this. +1 anyone feel like jumping volunteering to come up with a draft? Working on this now... Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
Here is a stab at replacement text for 15, 17 and 18. 15-1 Any member of the community may propose a new package. To be accepted, a package proposal must receive majority approval of the subproject committers and at least one committer must volunteer to serve as an initial package team member. Proposals should identify the rationale for the package, its scope, its interaction with other packages and products, the insert-subproject-name resources, if any, to be created, the initial source from which the package is to be created, and the sponsoring committers. 15-2 The subproject will maintain an svn repository, referred to as the isandbox/i, as a workplace for new packages. Once approved, new packages must all begin in the sandbox. Any apache committer may contribute code directly to the sandbox and this code may form the initial source for new packages. Code from existing apache projects can, with the support of the contributing projects, also be imported directly into the sandbox. Finally, patches contributed incrementally by community members may be committed to the sandox by a subproject committer. If the initial source for a new package is from outside of apache, the new package must be brought into apache via the apache incubator. 15-3 A majority vote among subproject commiters is required to graduate a package from the sandbox to become a proper package. Only proper packages may make releases. If a package remains in the sandbox for more than six months, a majority vote will be required to prevent its being archived from svn and removed from the subproject web site and any other public locations (e.g. nightly or continuous integration builds). Proper packages may not release code with dependencies on sandbox packages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Martin Cooper wrote: On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip Interpreted literally, 17 goes against standard practice in jakarta (or apache, to my knowledge, other than in the incubator). I would recommend that new packages require existing committers to support them. I would at least recommend changing Anyone to Any apache committer. If an individual has already contributed enough to be voted in as a committer, then that should be done in a separate VOTE. this certainly doesn't reflect the current practise in the jakarta commons. though anyone can propose a new component, they really won't have any chance of winning a VOTE unless they have the support of existing committers. there is also the issue of the incubator: any new component bringing code from outside apache would need to be incubated. We have a few different scenarios here, I believe. 1) A new component is proposed, with no existing code to back it up. I'm not sure that this has ever happened in Jakarta Commons, or is likely to happen in the new subproject, so frankly I don't much care about how that would work. ;-) 2) A new component is proposed by an existing Apache committer. This will almost certainly be backed up by code in the sandbox. Historically, in Jakarta Commons, there hasn't so much been a proposal, but rather a new project materialises in the sandbox. This has, in part, been responsible for dregs that lie around forever. This could be handled through the after 6 months vote that has been mentioned in another thread. 3) A new component is proposed by a non-committer. Code to back up such a proposal would necessarily be coming from somewhere else. This is a situation in which the component should, I believe, come in through the incubator. The incubation process would resolve the questions of committers, etc., before the component lands in the new subproject. (I want to emphasise here, for the folks that might be concerned about this, that incubation need not be an onerous process, and can happen rather quickly, if conditions are right.) I would suggest that we come up with wording in the charter to reflect these scenarios, rather than trying to crib from the Jakarta Commons charter in this instance. Agreed. After a little more discussion, we should rewrite this. FWIW, I did NOT mean to suggest that only committers could *suggest* projects, only that to actually get one *started*, support from ideally more than one committer is required. I think the following is also possible, since at least one j-c component started this way: 4) A new component is proposed by a (some) non-committer(s). One or more existing committers are interested in working on the component. The initial code base is built up incrementally in the sandbox from patches contributed by community members. This is more or less the way we started commons-math. The initial code base was contributed incrementally, with patches discussed, reviewed and in some cases refactored before being committed. I don't see anything wrong with this, nor requiring a trip through the incubator. Phil is 19 needed in addition to 15? This seems to be a different topic entirely, but my vote would be yes, because 15 relates only to the proposal, while 19 relates to the component as it exists, and is developed, within the subproject. +1 - different topic and one of the charming features of j-c that should, IMHO, be carried over. -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Stephen Colebourne wrote: robert burrell donkin wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 9 or somewhere else should speak to J2EE or other external config requirments, which should be fine, even encouraged in some cases is 9 needed? are any configuration guidelines needed? if they are then i agree that they should encourage specification compliance. would a general statement about specification compliance be better? Its not needed. The charter should be as simple as possible. +1 -- after thinking about it some more, I don't think it is wise to limit things or to reference J2EE or other specs in the charter. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for commons-like area for web
Stephen Colebourne wrote: There doesn't seem to be a thread for this The current suggestions are: Commons Web Jakarta Web Parts for Java (JWP4J) Web App Commons Web App Components Web App Modules Web Bricks Web Commons Web Components Web Libs Web Parts Web Tools Weblets Of these, WebParts has issues with Microsoft, so I would suggest we avoid it. Weblets was also used by IBM back in 2000, so could have issues. The most obvious would be CommonsWeb or WebCommons, as the general user community could link the concept to commons easily enough. However, there is a danger that it could be confusing precisely because of that. Thus, my current top three are: - WebLibs - WebCommons - WebBricks but I can still be persuaded. I like WebLibs the best. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Frank W. Zammetti wrote: In reading through this all, I have a concern that it will be difficult for any outside code to come in. Indeed it has proven difficult for many people I have spoken to to get code into any Commons project (although I myself had some things accepted, so clearly it is not impossible). This should be discussed on commons-dev if people really think it is an issue. Maintaining scope boundaries and quality is a key concern there (as it should be in the proposed project as well, IMHO), but *many* patches do get applied. What is the general feeling in terms of where the code comprising this package will come from? At least, the largest portion of it? The majority of the code should be developed collaboratively by the community, using the mailing list, Wiki, svn and issue tracker (Bugzilla or Jira) to discuss ideas and manage patches. Any significant contribution that is not developed within apache would have to go through the incubator before being integrated. snip/ is boils down to the question: does this subproject need it's own sandbox or will neophyte components start in the jakarta commons sandbox? I would not recommend reusing the j-c sandbox and I am not sure that I like the start components in the sandbox approach that we use there. Too many abandoned components that people start to use (and depend on) despite disclaimers. With the ease of branching in svn, I am not sure if a sandbox is really needed any more. In any case, I would not recommend repeating the j-c practice of incubating new subprojects in the sandbox. Just my HO. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Frank W. Zammetti wrote: I'm not sure I understand #12... is it talking about providing a JAR of a release for archival purposes? I think that in the early (actually as recently as a year or so ago) days of Jakarta Commons, a combo jar was produced that included *all* of the commons components (or at least the most commonly used ones), so that you could just deploy one jar and get them all. As robert points out below, internal and external dependencies and conflicts made that impractical, so, despite this reference in the charter, we no longer produce such a thing. I would like to see this project adopt the packaging scheme my own Java Web Parts project has in that each actual Java package is JAR'd separately. That way a developer can easily pick and choose which parts they want to use. +1 Phil I mention that because depending on what #12 really is talking about, that could conflict with that idea. I'm not sure. Frank robert burrell donkin wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip Don't know what kind of goo 12 would result in or who would use such a thing ;-) this has proved impractical in the jakarta commons. i propose we drop point 12. - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - 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] subproject that's a home for bricks reusable in java web applications
Stephen Colebourne wrote: robert burrell donkin wrote: there have been a number of long running threads in the commons discussing the possibility of commons components for use in web applications. the consensus emerged that it would be best if a new subproject with a structure similar to the commons was created for components intended for use in web applications. opinions, please! I am in favour of this, although whether I would be able to spare much time is debatable. I am also in favor, also not likely to have much time to contribute. Here are some comments on the draft charter. It is nice to see so much borrowed from the (at least I think) successful j-c model ;-) A couple of things should be changed, though, IMHO. First in the scope statement intended for use in server-related development could be narrowed to web application development Uniformly change CVS to SVN (I assume! :) 4.1 in the guidelines repeats the error that I thought was fixed in the j-c guidelines saying that each package has its own mailing list. If that is intentional, I think that is a *bad* idea, especially to start. 4.2 should probably reference JSP/Servlet spec level requirements as well as JDK requirements +1 to bullet under 7 :-) 9 or somewhere else should speak to J2EE or other external config requirments, which should be fine, even encouraged in some cases Don't like the many little lists implied by 11 -- dev + user works fine in j-c (I know some disagree, but I personally view this as the key to the health of j-c) Don't know what kind of goo 12 would result in or who would use such a thing ;-) Interpreted literally, 17 goes against standard practice in jakarta (or apache, to my knowledge, other than in the incubator). I would recommend that new packages require existing committers to support them. I would at least recommend changing Anyone to Any apache committer. If an individual has already contributed enough to be voted in as a committer, then that should be done in a separate VOTE. I guess 18 refers to the sandbox? I do not understand what the intent of this is. One final thing to think about. I know lots of apache people are opposed to umbrella projects for lots of reasons, one of which is the fragmentation and abandonment that can result. We have certainly not been immune to that in j-c. Two things that have been critical to keeping us going have been 1) a relatively small (changing over time) set of key contributors who look after multiple components and 2) some large internal customers (tomcat, struts, maven et al) whose committers jump in to push things along as needed. This project would be starting without the large internal customers. It would probably be a good idea, therefore, to start with a narrower, rather than broader scope, so that the fledgling community would not get fragmented too quickly and the key contributors could emerge. Just a thought. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [draft] SD Magazine: request for change
Henri Yandell wrote: snip/ You've pointed out that JBoss are the contributor in your commits, rather than yourself as an individual. I assume other JBoss employees are in the same situation. How does that change the email? Do I need to drop the paragraph about JBoss not being a contributor I have asked for clarification of what the CCLA means on legal-discuss, but it makes no sense to me that your statement below can be false: Two Tomcat committers are employed by JBoss Inc, but they commit to projects at the ASF as individuals and not as members of a company. This is true of all committers to the ASF, whether the company be Sun, IBM or Fred Bloggs Inc. If companies can in fact contribute directly, then it would seem to me that a) we should be voting them in as committers / PMC members and b) we should have policies and procedures for extending oversight to them. To my knowledge we (ASF) have no way of doing either of these things nor intention to develop them. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [site] New download pages
Thank you, Hen! Henri Yandell wrote: I'd like to go ahead and move to my suggested new download pages: http://jakarta.apache.org/~bayard/jakarta/site/downloads/downloads.html [X] +1 [ ] -1 or alternatively: [ ] +1, but fix this first: [ ] Currently the filenames match the names on the binindex.cgi page, I'm trying to stay as close as possible to the current site before making any other changes. It's easy enough to then do things like change 1.0.zip to hivemind-1.0.zip as Howard suggested. Post change, I'll focus on improving the Taglibs page to match the Commons one in style. 72 hour consensus vote. ie) a single -1 is a veto. Hen - 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: [site] Label for promoted Jakarta project
Hate to push us around in a circle, but what exactly was so bad about Related? Phil -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wed 1/12/2005 1:59 PM To: Jakarta General List Cc: Subject: Re: [site] Label for promoted Jakarta project That's the bit I'm trying to avoid. When a new TLP turns up, we have to modify our site. Which we're just not in the loop for. Something moving out of Jakarta, we're completely in the loop for and can catch it, we just don't know what to call it. OJB is a theoretical problem, it's now db-ojb. Log4j is the same, now logging-log4j. We've not really had a case where it was a huge problem; log4j is the mainstay of logging and ojb was barely in Jakarta, but still. Problem. Hen On Wed, 12 Jan 2005, robert burrell donkin wrote: i'm not really sure there's any good solution to this one. the downside of ex-jakarta is that it's inaccurate: logging isn't really ex-jakarta since it contains more than log4j. i wonder whether we could fit in every apache project and just label it Apache Projects... - robert On 9 Jan 2005, at 00:42, Henri Yandell wrote: At the bottom of the left hand navbar is a section of projects that used to be a part of Jakarta. It used to be Related and is currently Graduated, but neither name has won fans. Martin has suggested 'Ex-Jakarta'. A problem with Graduated is that it involves explaining, and also that it is a poor label as it is not a noun. Ex-Jakarta wins on both of these. Ex-Jakarta has another advantage that I see, which is that things don't have to goto an Apache TLP to be Ex-Jakarta. OJB for example, in db.apache.org, or even to somewhere like Sourceforge. So, any opinions? Barring any -1's to Ex-Jakarta, I'll make the change on Wednesday night. Hen - 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] - 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: Jakarta download pages Was: download pages in j.a.o.
Henri Yandell wrote: On Tue, 28 Dec 2004, Phil Steitz wrote: Henri Yandell wrote: On Tue, 28 Dec 2004, Martin Cooper wrote: I think, if we had a standard template for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects didn't have to really care about it; ie) they'd just link to: http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip You can link directly now, using the anchors in the main Jakarta download pages, e.g. http://jakarta.apache.org/site/binindex.cgi#commons-math Yep. There are two poor things about this: 1) As with the new header, it means most people jump the text on keys/md5 etc. Ack. Had not thought about this. I guess that's why most do not link directly now... 2) It seems pointless from a user point of view. The bit they're interested in is very small compared to the size of the whole page they're being dumped in. Agreed in general, though grabbing multiple commons components is something that some people need to do now and then (at least I have). The struts download page is a lot nicer from a user point of view, though one criticism is that the pgp/key stuff is at the bottom of the page there and unlikely to be seen by a downloader too. It's also serving more than one file. I'd like to see each project with links to something like: http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip which would show a page that automatically does the pgp/md5 blurb, links to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles the mirror stuff. We'd use the download.cgi for both binary and source. Sounds good to me. In this case, would we rectify the old components j-c page to present download links to each of the commons components? Phil Hen - 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: Jakarta download pages Was: download pages in j.a.o.
Henri Yandell wrote: On Tue, 28 Dec 2004, Martin Cooper wrote: I think, if we had a standard template for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects didn't have to really care about it; ie) they'd just link to: http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip You can link directly now, using the anchors in the main Jakarta download pages, e.g. http://jakarta.apache.org/site/binindex.cgi#commons-math I notice that some projects use direct links like this from their project pages and some do not. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] moving jakarta-site2 to subversion
I am +1 for this move and the plan. One thing that folks should be warned of, however, is that changing the directory structure will break site builds that depend on paths like ../jakarta-site2/xdocs/stylesheets, so these will have to changed when these projects nove. I don't know how many sites still do this - tomcat-site could be the only one. Tim O'Brien wrote: This is the simplest SVN migration in Jakarta. The migration instructions follow for review: http://wiki.apache.org/jakarta/Site2_20Conversion_20Instructions 72 hours for this vote - classify this as a public release vote requires majority (at least 3 +1s and more +1s than -1s ) [ ] +1, migrate jakarta-site2 CVS to /jakarta/site SVN [ ] +0 [ ] -0 [ ] -1, No - 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: jakarta commons net build failed
Ant cannot find the junit jar that it needs, despite the fact that it is grabbing it as a dependency :-( Look in $ANT_HOME/lib and make sure that both junit.jar and optional.jar are there, since that is where ant will look for them. You can copy the downloaded junit jar from target/lib if you like. For future reference, you should post questions about Jakarta Commons components to [EMAIL PROTECTED] hth, Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Updating PMC bylaws
+1 Phil Suggested new bylaws are at: http://www.osjava.org/~hen/jakarta/management.html The aim is to identify the current reality, rather than plan out a new set of bylaws. I believe I've responded to the past week of comments, sometimes by dropping things from the text as they require discussion (ie: active/inactive projects). Voting rules are that we need at least 3 +1 _PMC votes_, and a 3/4 majority of +1's to -1's. I'll announce results next Tuesday. === [ ] +1 - let's do it [ ] -1 - not good === I think the above voting rule is fair enough, though there are others we could use. Let's not worry too much about it unless we have major disagreements. Also, if people have non-voting commentary, it would be nice if they could change the subject (ie: Madness Was: [VOTE] Updating PMC bylaws). Makes counting the votes a lot easier. Hen - 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: [VOTE] HiveMind as a Jakarta sub-project
Geir Magnusson Jr wrote: All Jakarta Community Members : Howard M. Lewis Ship, on behalf of the committers of the HiveMind project in the Jakarta Commons sandbox, has proposed HiveMind as a Jakarta sub-project. The proposal was sent to this list, a copy of which can be found here : http://www.mail-archive.com/[EMAIL PROTECTED]/msg09244.html Please read the proposal and vote, and add any comments you deem appropriate. All Jakarta community members are encouraged to vote, although only the votes of the PMC members are legally binding as per the ASF*. [X] +1 I support this proposal [ ] -1 I don't support this proposal [ ] 0 I abstain from voting for or against this proposal Comments: Section (2) of the proposal refers to the Jakarta Commons incubator. This should be changed to Jakarta Commons Sandbox. In agreement with Noel, I would also suggest that the community consider the Apache Subversion Repository as an alternative to CVS. I see this as a HiveMind community decison, however -- i.e., I am +1 to the proposal regardless of the repository choice. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [License] for jars in CVS
Harish Krishnaswamy wrote: I am with Erik on no JARs in CVS. Unless it is a legal issue, I would certainly like to distribute all JARs with the distribution. It saves a lot of hassle and keeps uncessary traffic out of the user-list. At the expense of lots of wasted bandwidth and disk space. I agree with Robert. Think about how many copies of commons-collections.jar we would have in CVS (and on our local drives) if all projects stored all of their dependent jars in CVS. You can bundle dependent jars in the distributions without storing them in CVS. See the tomcat and struts distros and builds. I understand Erik's point about wanting to version the dependencies, but I don't think that storing dependent jars in CVS is a good general policy for Jakarta projects. As noted elsewhere on this thread, there are also legal issues to consider for non-Apache jars. Phil -Harish Erik Hatcher wrote: In jakarta-tapestry/lib/ext lives all of the licenses of the embedded 3rd party libraries. In that directory is a LICENSE.ognl.txt which contains the full license. I believe this is all that is needed to satisfy the license to redistribute the binary version. I can assure that you we will never ever have a problem with OGNL (Drew is a good friend of mine, and having the high profile use of OGNL in Tapestry and other projects like WebWork2 is great advertising for him and his genius). As for the larger issue of no JARs in CVS - I disagree. I'm pragmatic and also like to have everything in CVS needed to build a distribution (even Ant itself for my employers projects). It saves a lot of hassle to version all source code and dependencies together. Yes, we could make the Maven repository argument, but I personally prefer the complete offline usability of a CVS snapshot. When Tapestry came to Jakarta, it's dependencies were vetted extensively and several were removed from CVS - so it is still a PITA to build Tapestry from CVS (and according to Howard, his attempts to Mavenize the build have been unsuccessful to date). Erik On Dec 24, 2003, at 3:47 AM, Henri Yandell wrote: As I just happened to notice this on Incubator [AltRMI in fact]: Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? The below is, to my quick glance, a BSD licence, so approved. I'm with you on the no jars in CVS, but each to community to their own. Whether Tapestry is properly fulfilling the licence by listing their use of ognl in their documentation would be something to check on. Hen On Wed, 24 Dec 2003, Robert Leland wrote: Can we really store non Apache licensed jars in the CVS ? My personal preference is to store no jars in CVS For Example I noticed ognl stored in Tapestry CVS : / /- - //Copyright (c) 2002, Drew Davidson and Luke Blanshard // All rights reserved. // //Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions are // met: // //Redistributions of source code must retain the above copyright notice, // this list of conditions and the following disclaimer. //Redistributions in binary form must reproduce the above copyright // notice, this list of conditions and the following disclaimer in the // documentation and/or other materials provided with the distribution. //Neither the name of the Drew Davidson nor the names of its contributors // may be used to endorse or promote products derived from this software // without specific prior written permission. // //THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, // BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS // OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED // AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, // OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF // THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH // DAMAGE. // - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Ted Husted wrote: (Again, sorry about the quoting.) o·ver·sight 1. An unintentional omission or mistake. 2. Watchful care or management; supervision http://dictionary.reference.com/search?q=oversight The board expects PMCs to exercise (2) so as to avoid (1). :) For a PMC this boils down to issues of committer consensus and intellectual property. In the past, there have been incidents at Jakarta on both counts that lead to suspension of access, for both individuals and modules (on different occasions) IMHO, if we were to * require subprojects to file regular reports with bullets regarding consensus and oversight, and * subscribe all committers to the PMC list where these reports are filed then we'd be able to defuse these happenstances before they turn into incidents. Thanks for directly addressing the oversight issue. This looks like a good plan to me. Can you explain a little more a) what kinds of issues we need to worry most about; b) what kinds of things should go into the reports; and c) how subproject committers could share the responsibility of creating the reports. IMHO, the one and only set of individuals that can provide watchful care over a codebase is the set of committers we already have for each subproject. I agree. IMHO, each and every committer to a Jakarta subproject has already passed through a gauntlet that proves they are PMC material and entitled to binding votes. Until I understand fully what the responsibilities are, I am not sure that I agree with this, partly because subproject committers may not have signed up for a role beyond the subproject. I agree with your statements about votes being binding, however, so we clearly need to change (or legalize ;) something. All we need to do is complete the process that promotes our committers to PMC members with binding votes, as our original guidelines contemplated, and require subprojects to provide regular status reports. (Just as the board requires our project to report.) This will solve the problem of committers having binding votes on the codebase that they work on, but it may not be the best solution for the Jakarta PMC. Is it totally out of bounds from the ASF perspective to allow subproject committers to have binding votes for their subprojects without being PMC members? I know that this has been discussed and categorical statements have been made, but I frankly do not get it. If the Jakarta PMC reviews and aggregates all of the subproject reports and includes representation from each of the subprojects, where is the gap in oversight? I don't mean to be argumentative or dense here, but it is very important that we understand clearly what the constraints are (and why these constraints exist, and whether they can be changed as the ASF scales). As both Roy and Greg have said, if the Jakarta committers truly understood how few rights and privileges they have, they would be demanding both ASF and PMC membership. Few do, so few have. IIUC, it is mostly a matter of legal protection, not so much rights and privileges (unless you view indemnification as a right or privilege). Here again, a little more background / facts would be helpful, as well as some indication of what is written in stone and why that is so. Phil -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Stephen Colebourne wrote: Not really (my POV) As people we naturally think in terms of the hierarchy ASF to Jakarta to MySubProject. But the middle layer is artificial. It could just as well be XML or DB or WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe Bloggs works'. There simply is no one way of categorizing, hence there actually is no one community either. (ie. 'the jakarta community' simply does not exist in my eyes) I agree that we probably can't define Jakarta in terms of content in a way that will make everyone happy. I disagree, however, that this means that there is no community, or that Jakarta should be dissolved. I would say that Jakarta = the community. What are called Products on the web site are what this community produces. Java is one common denominator, but so are some common release management and decision-making practices (currently under debate / revision). I am much less bothered than others about the fact that not *all* server-side Java in Apache is in Jakarta or that some Jakarta projects might belong elsewhere. I really don't see why this is a problem. The only real problem that we have is making sure that we have sufficient oversight. The middle layer makes that look like more of a challenge, but that's only if you assume that oversight has to come from a small number of Jakarta PMC members. Growing the PMC (as we are now) so that all community activity has has direct PMC oversight will solve the oversight problem. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [website][patch] Add instructions for setting up mail to newbie.xml
Tetsuya Kitahata wrote: Hi, Phil and all. Did you make it? If you failed, I think i can apply the patch for it (I am *not* subscribing to infrastructure@, now). I did make the patch and posted it in an email to infrastructure@ on 11/23. It has not been applied. I am attaching the patch to site/xdocs/dev/committers.xml that I created on 11/22. If we do get this applied, we should change the Jakarta Newbie page to point to this for mail account setup questions. Phil Index: xdocs/dev/committers.xml === RCS file: /home/cvspublic/site/xdocs/dev/committers.xml,v retrieving revision 1.17 diff -u -r1.17 committers.xml --- xdocs/dev/committers.xml7 Nov 2003 21:15:38 - 1.17 +++ xdocs/dev/committers.xml24 Nov 2003 02:20:02 - @@ -288,6 +288,32 @@ titleMail Questions/title section +titleHow do I setup my email account?/title + +pYou can use ssh and Pine, put a .forward file in your user directory +to forward your mail to another account, or use ssh tunneling to +send/receive mail using a mail client./p + +pOne way to create a .forward file is to use ssh to login to +cvs.apache.org and then execute the following commands: +pre + vi .forward + i your_normal_email + ESC :x +/pre/p + +pTo set up an ssh tunnel for both sending and receiving, run the +following from your local machine (may require root access):/p +pcode +ssh [EMAIL PROTECTED] -L X:locahost:110 -L Y:localhost:25 +/code/p + +pwhere codeX/code and codeY/code are available local port +numbers. Then configure your mail client to use codelocalhost:X/code + to receive and codelocalhost:Y/code to send./p +/section + +section titleHow do I request the creation of a new mail list?/title pMail lists are the virtual room where the communties live, form and - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Agreeing new voting rules for Jakarta
Robert Leland wrote: Phil Steitz wrote: Noel J. Bergman wrote: It seems odd to me that code changes effectively require consensus, but a release would not. What am I missing here? All code in CVS is already there on consensus. As are the bugs ;-) Seriously, this seems like sort of a grey area between technical, code-related (so needing consensus) and policy. The decision to cut a release has technical implications (e.g. backward compatability), but it is not a technical decision per se. I am not pushing for this, just trying to understand better how we look at releases. There are two schools. For Struts 0.5, 1.0 , 1.1 we used the criteria that all bugs had to fixed or marked as later. As a result between 0.5 and 1.0 took 12 months and between 1.0 and 1.1 took 20 months. For Struts 1.2 we agreed to switch to the x.y.z style that Apache HTTPD and Tomcat are using, where you post the bits and then call for a vote on stability (alpha/beta/general availability). A release can also be withdrawn. After a release there is often a flood of new users, and a few, usually very few new bug reported. More importantly there are improvements new users make and hopefully share as they tinker with and extend Struts to make it fit their needs. It's this synergy that is good for the project. We tried it the other way first and while we were always making progress on the software, the development could have easily stagnated. Between Struts 1.0 and 1.1 we were fortunate enough to vote in about 8 committers, each gave the software development a much needed boost. By releasing more often we hope to actually increase the quality, by the fact of greater participation from the app developers. It's easier to do this now in Struts since presently it is in an evolutionary mode. Also I would say that Tomcat and HTTPD are two of the most successful projects Apache has so they have to be doing something right. Thanks for the perspective, Robert. Does this mean you are in favor of having release votes just require majority approval? After re-reading http://jakarta.apache.org/site/decisions.html carefully, I am in favor of keeping things as stated there -- Release Plans require lazy majority, but Release Testing just requires majority approval. Phil - 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: jakarta-future Was: [POLL] Future Of Turbine-JCS
Henri Yandell wrote: On Wed, 2 Oct 2002, Costin Manolache wrote: 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. +1 to jakarta-wide karma. It'd be interesting to look at all the mail-traffic for Jakarta and estimate just how noisy a single project mail list would be. It would be very noisy, indeed. Here are some stats from October (from message counts displayed at http://marc.theaimsgroup.com) struts tomcat commons user 3115 2908 375 dev 759 1131 2112 Then maybe instead of breaking it on code-base, we could break it on concept: jakarta-bugs jakarta-announce jakarta-dev jakarta-pmc jakarta-ideas jakarta-site or something. I'm assuming it'll be too noisy, but it is a logical question to ask based on Costin's ideas of opening things up. I understand that the oversight role of the PMC has to include all of Jakarta and I agree that some form of list aggregation/digesting might need to happen to make this practical. I don't think that combining all of the lists is the right way to do it though. This would certainly be a pain for users and contributors who may be interested in only a small number of projects. One way to attack the problem might be to have PMC members who are committers on the different Jakarta projects share the responsibility of maintaining list digests for periodic (weekly?) review by the full PMC and/or alerting the full PMC of any issues that require immediate attention. I guess the alternative would be for all of us to subscribe to all of the lists and take up speed reading ;-) Apologies if this is old ground. I am new to the PMC. Phil Hen - 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]
