cvs commit: xml-site/targets/axis releases.html intro.html
gdaniels2002/12/03 08:10:12 Modified:targets/axis releases.html intro.html Log: 1.1 beta release Revision ChangesPath 1.16 +7 -2 xml-site/targets/axis/releases.html Index: releases.html === RCS file: /home/cvs/xml-site/targets/axis/releases.html,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- releases.html 7 Oct 2002 17:21:03 - 1.15 +++ releases.html 3 Dec 2002 16:10:11 - 1.16 @@ -21,16 +21,21 @@ tdbDescription/b/td /tr tr +tda href=http://xml.apache.org/axis/dist/1_1beta;1.1beta/a/td +tdDecember 3, 2002/td +tdBeta for 1.1 release/td + /tr + tr tda href=http://xml.apache.org/axis/dist/1_0/;1.0/a/td tdOctober 7, 2002/td tdRelease 1.0./td /tr - tr + tr tda href=http://xml.apache.org/axis/dist/1_0rc2/;1.0rc2/a/td tdSeptember 30, 2002/td tdRelease Candidate #2 for version 1.0./td /tr - tr + tr tda href=http://xml.apache.org/axis/dist/1_0rc1/;1.0rc1/a/td tdSeptember 6, 2002/td tdRelease Candidate #1 for version 1.0./td 1.21 +2 -1 xml-site/targets/axis/intro.html Index: intro.html === RCS file: /home/cvs/xml-site/targets/axis/intro.html,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- intro.html7 Oct 2002 17:21:03 - 1.20 +++ intro.html3 Dec 2002 16:10:11 - 1.21 @@ -12,7 +12,8 @@ /tr /table -pNEWS (October 7, 2002) : Axis a href=http://xml.apache.org/axis/dist/1_0/;1.0/a is now available! +pNEWS (December 3, 2002) : Axis a href=http://xml.apache.org/axis/dist/1_1beta/;1.1 + beta /a is now available! hr pApache AXIS is an implementation of the SOAP (Simple Object Access Protocol) a href=http://www.w3.org/TR/SOAP; target=_topsubmission/a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Sam Ruby wrote: Merge or diverge. Having community boundaries distinct from PMC boundaries is not sustainable. And what about Commons and Commons-Sandbox? One can imagine these as the refugee camps for smallish subprojects, without the 'community' to go toplevel. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/ http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/ might contain a lot of subprojects which doesn't fit your criteria sizewise. Should these all be put back to incubator stage? Or do they share a common 'Commons' community? I understand your point that a single PMC overlooking a lot of scattered projects doesn't scale. Still, I believe some of these smallish subprojects can share a common spirit, without sharing the developers community. Merging all of these will make them less visible to the outside world IMHO - meaning developers can meet, merge or exchange, but to prospective users it will all be one big sinkhole. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0103539/ stevenn at outerthought.orgstevenn at apache.org - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Steven Noels wrote: Sam Ruby wrote: Merge or diverge. Having community boundaries distinct from PMC boundaries is not sustainable. And what about Commons and Commons-Sandbox? One can imagine these as the refugee camps for smallish subprojects, without the 'community' to go toplevel. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/ http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/ might contain a lot of subprojects which doesn't fit your criteria sizewise. Should these all be put back to incubator stage? Or do they share a common 'Commons' community? I understand your point that a single PMC overlooking a lot of scattered projects doesn't scale. Still, I believe some of these smallish subprojects can share a common spirit, without sharing the developers community. Merging all of these will make them less visible to the outside world IMHO - meaning developers can meet, merge or exchange, but to prospective users it will all be one big sinkhole. IIUC this is to gently nudge them to go top-level with their own PMC. If they want visibility, they need take also the responsibilities. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Steven Noels wrote: Nicola Ken Barozzi wrote: I understand your point that a single PMC overlooking a lot of scattered projects doesn't scale. Still, I believe some of these smallish subprojects can share a common spirit, without sharing the developers community. Merging all of these will make them less visible to the outside world IMHO - meaning developers can meet, merge or exchange, but to prospective users it will all be one big sinkhole. IIUC this is to gently nudge them to go top-level with their own PMC. If they want visibility, they need take also the responsibilities. I agree this is a good solution for the large projects with an active community (e.g. Cocoon in the xml.a.o case). Still, I'm not sure whether the board needs this avalanche of toplevel projects, all required to post their STATUS once in a while, all present upon meetings, etc etc... we'll just move the scalability problem one level up, I fear. No, we are putting *responsibility* where it belongs. Top level projects have a chair who is legally representative of Apache, and should manage themselves. Having the whole Jakarta PMC manage them is too much. What we want to do is not to shift the management to the board, but to maki it go to the projects. Less structure, more responsibility. Also, I don't know whether this approach will help smaller communities to mix merge: they'll get lost without some proper identity. Do we want incubator or commons to contain that many projects? How many people will still have the overview? Apart from having all commit privileges to all jakarta projects, I don't see why this will necessarily change communities. They don't have to mix and merge, they are simply becoming aware that they are part of Jakarta, or have to go top-level. Increasing awareness of what Jakarta and Xml.Apache really are - projects - instead of pretending they are smaller Apaches. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Steven Noels wrote: Nicola Ken Barozzi wrote: Steven Noels wrote: Less structure, more responsibility. ACK Also, I don't know whether this approach will help smaller communities to mix merge: they'll get lost without some proper identity. Do we want incubator or commons to contain that many projects? How many people will still have the overview? Apart from having all commit privileges to all jakarta projects, I don't see why this will necessarily change communities. They don't have to mix and merge, they are simply becoming aware that they are part of Jakarta, or have to go top-level. Increasing awareness of what Jakarta and Xml.Apache really are - projects - instead of pretending they are smaller Apaches. Point taken agree. Getting back to the original question however, it felt like Ted (as XML PMC member) came to ask us what this XML project needs to be, i.e. what the XML PMC should take care off. If everyone leaves and becomes a toplevel project (which I don't believe will happen), what will happen to the XML project then? If (as you believe will not happen) not all projects become top-level, there is no problem. If all go top-level, they will be happy of it, since they are not obliged to do it, so itìs still not a problem. Bottom line: tell everyone what should be done, ie top-level or in the same xml project. If something is needed, it will naturally remain. If it's not it will naturally go away. - No problem :-) I'll think some more about that. /Steven -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
On Mon, Dec 02, 2002 at 01:12:25PM -0800, Ted Leung wrote: ... I feel that the level of oversight that is being provided for the xml.apache.org projects is insufficient. In what way? Beyond ensuring nobody checks in (L)GPL'ed jars, or code without copyrights, and the projects are not getting the help/guidance/whatever that they need from the ASF. Well it would be nice to have someone to ask if, say, activation.jar is allowed in CVS, but does it take more than 7 people on pmc@ to answer this? ... Please express your opinions! Let's clarify exactly what is broken before fixing it. --Jeff Ted - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
On Tue, 3 Dec 2002, Jeff Turner wrote: On Mon, Dec 02, 2002 at 01:12:25PM -0800, Ted Leung wrote: ... I feel that the level of oversight that is being provided for the xml.apache.org projects is insufficient. In what way? Beyond ensuring nobody checks in (L)GPL'ed jars, or code without copyrights, and the projects are not getting the help/guidance/whatever that they need from the ASF. Well it would be nice to have someone to ask if, say, activation.jar is allowed in CVS, but does it take more than 7 people on pmc@ to answer this? ... Please express your opinions! Let's clarify exactly what is broken before fixing it. That is a fair question ! And certainly not one I've got a good answer for. Part of it ties into our being of a US incorperated; part of it is defined in our bylaws. But we are at this point most certainly devoid of an itemized list. Dw - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Steven Noels wrote: If everyone leaves and becomes a toplevel project (which I don't believe will happen), what will happen to the XML project then? I think too much effort is being expended trying to decide between everything being a top-level project or kept within a project group (e.g. XML, Jakarta). And the problem is intensified by the fact that there are projects that cross boundaries. So why have these boundaries at all? Instead of thinking of where each project feels comfortable developing, we should be thinking about how users find the projects and solutions that they need. Users, especially new ones, don't approach Apache thinking that they need Tomcat and Cocoon; they are looking for a server application that lets them dynamically generate web pages using XML. So I say make every project independent (unless there is a direct, mandatory dependency -- i.e. a sub-project) and then allow each project to decide which taxonomy (or taxonomies) that are appropriate. -- Andy Clark * [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Andy Clark wrote: So I say make every project independent (unless there is a direct, mandatory dependency -- i.e. a sub-project) and then allow each project to decide which taxonomy (or taxonomies) that are appropriate. Is that something you plan to mandate and enforce? If so, how? Should what was once Apache Jakarta Avalon Excalibur Threadcontext be a separate project, or is it sufficient for Avalon to be a separate project (as it is now)? As to Jeff's question as to what's broken, clearly Jakarta was not providing sufficient oversight to the Avalon code base - license violations were made and Apache processes were not being followed. The correct solution was to make Avalon self-sufficient. This process is well underway. Ted is questioning whether or not the XML PMC is providing sufficient oversight. It is a valid question. The guidelines I would suggest for establishing a PMC boundary is one of whether one where you would want the karma boundaries to be placed... example: should Xerces and Xalan have a unified set of committers or should these lists be separate? This is a question that can be resolved in bottom up manner. - Sam Ruby - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Removal
All: I don't mean to be rude but I have sent several notes to unsubscribe to be removed from the list and even e-mailed the webmaster. Could someone please resolve this issue and remove me from the list? Thanks, Scott Scott DeWitt Software Engineer Transcoding Technology IBM Pervasive Computing __ [EMAIL PROTECTED] (919) 486.1919 t/l 526.1919 - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Not to pollute the discussion too much, but I just recently became a part of one xml.apache.org project, and have been a member of the Apache community only about 6 months. Before I got involved, though, I was using both Jakarta and xml.apache.org software for quite a while. To me the xml.apache.org brand was always a subsidiary brand of ASF, as was Jakarta. It carries enough weight that I have looked here first when I need a piece of software for a project, and will try an Apache project out before a random Sourceforge one every time. Where I work, Apache is a web server. Jakarta IS Java (or alternatively its where you get struts and tomcat). XML.apache.org is where Xerces is hidden. -Andy $0.02 -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Removal
Scott Dewitt wrote: All: I don't mean to be rude but I have sent several notes to unsubscribe to be removed from the list and even e-mailed the webmaster. Could someone please resolve this issue and remove me from the list? To unsubscribe, e-mail: [EMAIL PROTECTED] This doesn't work? You should get a confirmation e-mail, and upon replying to that you should be out. Or try list-help: mailto:[EMAIL PROTECTED], that should send you an e-mail with detailed instructions. Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Linux Migration Project: http://www.linux-migration.org/ Red Hat Linux 7.3 for low memory: http://www.rule-project.org/ Registered Linux user #210635: http://counter.li.org/ - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Removal
You also need to make sure that you unsubscribe using the same email address that you subscribed with. -Original Message- From: Martin Stricker [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 8:14 PM To: [EMAIL PROTECTED] Subject: Re: Removal Scott Dewitt wrote: All: I don't mean to be rude but I have sent several notes to unsubscribe to be removed from the list and even e-mailed the webmaster. Could someone please resolve this issue and remove me from the list? To unsubscribe, e-mail: [EMAIL PROTECTED] This doesn't work? You should get a confirmation e-mail, and upon replying to that you should be out. Or try list-help: mailto:[EMAIL PROTECTED], that should send you an e-mail with detailed instructions. Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Linux Migration Project: http://www.linux-migration.org/ Red Hat Linux 7.3 for low memory: http://www.rule-project.org/ Registered Linux user #210635: http://counter.li.org/ - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
[let's keep this on [EMAIL PROTECTED] please] Steven Punte wrote: To date, my understanding of open source software is that it expresses no warranty at all. I'm unclear on what basis someone would be held libel in a legal action. Patent infringements? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0103539/ stevenn at outerthought.orgstevenn at apache.org - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Jeff Turner wrote: On Tue, Dec 03, 2002 at 02:59:52PM +0100, Nicola Ken Barozzi wrote: Jeff Turner wrote: [...] Let's clarify exactly what is broken before fixing it. If you are not part of a PMC, you have no legal protection from the ASF. I understood that: - the ASF legal entity is there to protect ASF _members_ - PMC member != ASF member. Eg, we're both Avalon PMC members, but if someone were to sue us, that would not benefit us. Thus, forming PMCs and flattening the structure in no way lessens the legal risk taken by non-member committers (the vast majority). If I'm wrong on this important point, please correct me. IANAL, but PMC members have some form of protection. The PMC is formally appointed by Apache to look over a project, and thus operates under its request (by the board) and oversight (chair and board). The ASF will protect the people it appoints. That still leaves the question: in what way is the current XML PMC failing in its duties. What do you think its duties are? I can see that the Jakarta PMC might have missed stuff happening in the depths of Commons and Avalon, but xml.apache.org is a much quieter place. The Xml PMC cannot review all code commits and placement of jars and licenses, and at the same time ensure that the Apache process for guidelines is followed, it's just too much work. How much time has the xml site been in need of an overhaul and fixes? How come the Xang project was still listed in the same space as the other active projects? Where is the STATUS file detailed in the guidelines (http://xml.apache.org/source.html#N10028) in most projects? These points do not seem to be clearly part of the PMC mission ATM http://xml.apache.org/management.html , but in fact are. ATM it's humanly impossible for the Xml PMC to do all this with all the projects and communities it has. snip good quotes /snip good quotes -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
One way of looking at Jakarta Commons Sandbox is as a kind of incubator. So you could argue that those projects should move to incubation... - Original Message - From: Steven Noels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 03, 2002 12:45 AM Subject: Re: The organization of xml.apache.org Sam Ruby wrote: Merge or diverge. Having community boundaries distinct from PMC boundaries is not sustainable. And what about Commons and Commons-Sandbox? One can imagine these as the refugee camps for smallish subprojects, without the 'community' to go toplevel. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/ http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/ might contain a lot of subprojects which doesn't fit your criteria sizewise. Should these all be put back to incubator stage? Or do they share a common 'Commons' community? I understand your point that a single PMC overlooking a lot of scattered projects doesn't scale. Still, I believe some of these smallish subprojects can share a common spirit, without sharing the developers community. Merging all of these will make them less visible to the outside world IMHO - meaning developers can meet, merge or exchange, but to prospective users it will all be one big sinkhole. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0103539/ stevenn at outerthought.orgstevenn at apache.org - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
- Original Message - From: Nicola Ken Barozzi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 03, 2002 2:34 AM Subject: Re: The organization of xml.apache.org Steven Noels wrote: Nicola Ken Barozzi wrote: Steven Noels wrote: Less structure, more responsibility. ACK Also, I don't know whether this approach will help smaller communities to mix merge: they'll get lost without some proper identity. Do we want incubator or commons to contain that many projects? How many people will still have the overview? Apart from having all commit privileges to all jakarta projects, I don't see why this will necessarily change communities. They don't have to mix and merge, they are simply becoming aware that they are part of Jakarta, or have to go top-level. Increasing awareness of what Jakarta and Xml.Apache really are - projects - instead of pretending they are smaller Apaches. Point taken agree. Getting back to the original question however, it felt like Ted (as XML PMC member) came to ask us what this XML project needs to be, i.e. what the XML PMC should take care off. If everyone leaves and becomes a toplevel project (which I don't believe will happen), what will happen to the XML project then? If (as you believe will not happen) not all projects become top-level, there is no problem. If all go top-level, they will be happy of it, since they are not obliged to do it, so itìs still not a problem. Bottom line: tell everyone what should be done, ie top-level or in the same xml project. If something is needed, it will naturally remain. If it's not it will naturally go away. I am not trying to tell anyone or any project what to do. I am trying to help the xml.apache.org community understand some issues which I did not understand that well myself until recently.I haven't come to a conclusive opinion on what should be done. Sam and I talked at ApacheCon, and at the point where that discussion occurred, I was feeling very much that we ought to push the xml subprojects to become top level projects. A few days later I had lunch with Dirk, and he pointed out that top-leveling all the projects is not a panacea for some of the issues in some of the projects, and so my enthusiasm for top-leveling has cooled somewhat. My opinions on this are evolving. My hope is that as we discuss, people will be able to determine the merits of the various solutions for the projects that they are involved with, and take appropriate action. Ted - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The organization of xml.apache.org
Probably my largest concern has to do with ensuring that ASF style processes are being followed on all projects. This includes subjective measures such as the health of the community for a project, and proposal of project committers for membership in the ASF. Then there's the legal stuff, which includes the visibility to the board, jar files, code without copyright, code with incompatible copyright, code with patent infringements, etc. Then there's the issue of support from and participation in the general ASF infrastructure. That's where do I go for this or that, or You're really an awesome security hack, you know, they could use some help on security@. Ted - Original Message - From: Jeff Turner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 03, 2002 4:36 AM Subject: Re: The organization of xml.apache.org On Mon, Dec 02, 2002 at 01:12:25PM -0800, Ted Leung wrote: ... I feel that the level of oversight that is being provided for the xml.apache.org projects is insufficient. In what way? Beyond ensuring nobody checks in (L)GPL'ed jars, or code without copyrights, and the projects are not getting the help/guidance/whatever that they need from the ASF. Well it would be nice to have someone to ask if, say, activation.jar is allowed in CVS, but does it take more than 7 people on pmc@ to answer this? ... Please express your opinions! Let's clarify exactly what is broken before fixing it. --Jeff Ted - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
