Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Ted Husted wrote: At this point, I'm reconciled to do more work on the Jakata site using XML in the old-fashioned way. I can't resonate more with your feelings. That's exactly what made me started the 'forrest' effort: the coherence on xml.apache.org and the ease of update has been slowly falling apart until now when people can't even run in on their machines without getting fonts problems (yeah, blocked by fonts problems! go figure!) We have some unratified guidelines that expand on the ones (you?) originally set down. No, that wasn't me to edit that page, even if much was taken from my java.apache constitution (as you indicate below), which on my side, took from the old dev.apache.org guidelines for [EMAIL PROTECTED] http://jakarta.apache.org/site/proposal.html If you were able to review them, I would of course very much like to have your comments before making a final update and calling for a vote. I'm honored. I'll do it ASAP. I would also like to add more rationale for some of the guidelines. The recent dicussion regarding coding conventions had less to do with the conventions themselves, and more to do with why we even have conventions. (And having conventions, why don't we enforce them.) Good point. As Jakarta grows, it becomes more and more important that we have better ways to introduce peoole into the fold. Right now, there is a tendency to make someone a Committer and let them find their own way around. At this time, I'd like to go to work on a Committer's guidebook that would help explain how things are done (starting with How to do a Release -- which raised the JAR discussion the other day). Oh, gosh, you are probably unaware of the fact that I'm the one that continously pisses people off on the ASF member list (unfortunately private) about having those 'committer guidelines' up and running. James Davidson and I were the one who made the page on how to setup your SSH tunnel for CVS. Yes, this is the right direction, but people must commit to keep those guidelines up 2 date and many people (expecially apache root's) failed miserably to do it. Also we must make those easy to find. Again, Forrest will help. I think the real solution to improving the noise:signal ratio is to move away from the oral (email) tradition we have now, and move back toward providing more grassroots documentation, as you did in the preamble to the original constition. http://java.apache.org/main/constitution.html Absolutely. An actual history of Jakarta might also be useful to give people a better perspective. Here's one passages I tucked away (to be joined by your own snippets of late). Pier to Jon - Thu, 21 Dec 2000 We've traveled a long way together, from my very first steps in open-source land in January 1998, to our marvelous meeting at the first ApacheCON in October 1998, the Jakarta room meeting, all JavaONEs, and all we did together to bring this project where it is right now. Pier again, same day And we, as the newly formed Apache Software Foundation, accepted that code in donation as a point of start for the Jakarta Project. I was there, in that meeting room, that day when we outlined how the process would have evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE, when Patricia Sueltz announced the spinoff of the project againg with Jon, Stefano and Brian. If that has been a wrong decision, we four are the people to blame... A coherent history might help with many of the questions about why we do things the way we do. (Or why we don't do some things at all.) I think clearly documenting the Apache Way would be an important first step to unifying the Apache Projects. Great point. I absolutely agree. I would also like to personally commend Jon with his efforts to better document Jakarta. He has put a lot into the Web site (probably 90%), and we all owe him a great debt. Oh, I never even thought about questioning this. I personally owe everything to Jon: without his kind messages, I wouldn't have remained around the community enough to get the 'apache feeling' out of it. Jon and I have very different technical views and very different ways of doing software architectures and sometimes some friction develops, but all the times I land in SFO, he's the first one who I call to hang out with! :) [yeah, people, the 'rude' Jon Stevens was the one who gave Pier and I hospitality in his place when we came to ApacheCON 98 and we didn't have a place to stay since we had to pay our own expenses] Gosh, Ted, you're right, we should write this history down someplace and let people know how we came here. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. [EMAIL PROTECTED] Friedrich Nietzsche -- To unsubscribe, e-mail:
RE: On unity and coherence [was Re: [Request For Comment] POI @ apache]
As a newbie (only 1.5 years around) I found the small bio posted by Stefano on the Cocoon-dev list very interesting and instructive. This post was triggered by curiosity and know-your-community concerns that popped up in a couple of Cocoon-dev threads less than 2 months ago. IMO, the fact that it is written in the first person only helps. To ease the task of searching for it, I am just attaching it. Maybe Ted and others can use it as an historic source. Have fun, Paulo Gaspar -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 3:48 PM Ted Husted wrote: At this point, I'm reconciled to do more work on the Jakata site using XML in the old-fashioned way. I can't resonate more with your feelings. That's exactly what made me started the 'forrest' effort: the coherence on xml.apache.org and the ease of update has been slowly falling apart until now when people can't even run in on their machines without getting fonts problems (yeah, blocked by fonts problems! go figure!) We have some unratified guidelines that expand on the ones (you?) originally set down. No, that wasn't me to edit that page, even if much was taken from my java.apache constitution (as you indicate below), which on my side, took from the old dev.apache.org guidelines for [EMAIL PROTECTED] http://jakarta.apache.org/site/proposal.html If you were able to review them, I would of course very much like to have your comments before making a final update and calling for a vote. I'm honored. I'll do it ASAP. I would also like to add more rationale for some of the guidelines. The recent dicussion regarding coding conventions had less to do with the conventions themselves, and more to do with why we even have conventions. (And having conventions, why don't we enforce them.) Good point. As Jakarta grows, it becomes more and more important that we have better ways to introduce peoole into the fold. Right now, there is a tendency to make someone a Committer and let them find their own way around. At this time, I'd like to go to work on a Committer's guidebook that would help explain how things are done (starting with How to do a Release -- which raised the JAR discussion the other day). Oh, gosh, you are probably unaware of the fact that I'm the one that continously pisses people off on the ASF member list (unfortunately private) about having those 'committer guidelines' up and running. James Davidson and I were the one who made the page on how to setup your SSH tunnel for CVS. Yes, this is the right direction, but people must commit to keep those guidelines up 2 date and many people (expecially apache root's) failed miserably to do it. Also we must make those easy to find. Again, Forrest will help. I think the real solution to improving the noise:signal ratio is to move away from the oral (email) tradition we have now, and move back toward providing more grassroots documentation, as you did in the preamble to the original constition. http://java.apache.org/main/constitution.html Absolutely. An actual history of Jakarta might also be useful to give people a better perspective. Here's one passages I tucked away (to be joined by your own snippets of late). Pier to Jon - Thu, 21 Dec 2000 We've traveled a long way together, from my very first steps in open-source land in January 1998, to our marvelous meeting at the first ApacheCON in October 1998, the Jakarta room meeting, all JavaONEs, and all we did together to bring this project where it is right now. Pier again, same day And we, as the newly formed Apache Software Foundation, accepted that code in donation as a point of start for the Jakarta Project. I was there, in that meeting room, that day when we outlined how the process would have evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE, when Patricia Sueltz announced the spinoff of the project againg with Jon, Stefano and Brian. If that has been a wrong decision, we four are the people to blame... A coherent history might help with many of the questions about why we do things the way we do. (Or why we don't do some things at all.) I think clearly documenting the Apache Way would be an important first step to unifying the Apache Projects. Great point. I absolutely agree. I would also like to personally commend Jon with his efforts to better document Jakarta. He has put a lot into the Web site (probably 90%), and we all owe him a great debt. Oh, I never even thought about questioning this. I personally owe everything to Jon: without his kind messages, I wouldn't have remained around the community enough to get the 'apache feeling' out of it. Jon and I have very different technical views and very different ways of doing software architectures and sometimes some friction develops, but all the
RE: On unity and coherence [was Re: [Request For Comment] POI @apache]
Here we go again, -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 4:45 AM Playing Devil's advocate. I think it's fair to push back on adding things to Jakarta... On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? WHY for presentation? Most of the time you would batch convert Word and Excel docs to HTML if needed, and there are specialized tools for that. However, you point out in the above link that the thing that makes POI special is it's ability to *write*? What's the % of mainly writing to mainly reading on the serverside? As mentioned in my previous posting, it is JUST like Velocity writing HTML. http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html Paulo might use VB to make a client side app, but I wouldn't if I wanted portability, especially if I was looking to the handheld or embedded application that could access a document remotely... Are there many uses for writing Word/Excel documents in a client-side device that has not Word or Excel installed??? And AFAIK, if you have Word and Excel, you have at least some Basic scripting... but maybe you do not have Java. ... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
On 1/6/02 12:18 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: Here we go again, Alas. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 4:45 AM Playing Devil's advocate. I think it's fair to push back on adding things to Jakarta... On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? WHY for presentation? Most of the time you would batch convert Word and Excel docs to HTML if needed, and there are specialized tools for that. 'presentation' in the sense of 'reading data out to show in some manner', not 'on the desktop'. However, you point out in the above link that the thing that makes POI special is it's ability to *write*? What's the % of mainly writing to mainly reading on the serverside? As mentioned in my previous posting, it is JUST like Velocity writing HTML. Huh? You have to explain that a little more - I don't quite get it. http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html Paulo might use VB to make a client side app, but I wouldn't if I wanted portability, especially if I was looking to the handheld or embedded application that could access a document remotely... Are there many uses for writing Word/Excel documents in a client-side device that has not Word or Excel installed??? You might find this unbelieveable, but not everyone works on a computer that runs an operating system that has Word or Excel available. And AFAIK, if you have Word and Excel, you have at least some Basic scripting... but maybe you do not have Java. ... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: On unity and coherence [was Re: [Request For Comment] POI @apache]
Again... -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 6:14 PM On 1/6/02 12:11 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: ... Lots of is it server or is it client talk ... I just mean that sometimes saying that something is server-side or client-side just makes no sense. As Ceki puts it, maybe JMeter is one of the few clearly server-side products in Jakarta. BTW... is Log4J server-side? =;o) From what I read, POI is an API that accesses data in XLS files... Theres a huge difference. And Cocoon isn't part of Jakarta, is it? :) JUST because it is XML centric, which POI is not. Right. I wasn't advocating it going to XML-land - it doesn't seem to belong there either. It am still not aware of any valid argument that clearly states why it does not belong to Jakarta or why it belongs. It is just like BCEL or Log4J - some people wanted those projects here because they had use for them or were already using them. Nothing to do with serversideness!!! BTW, do you know they use Velocity for something??? Who, POI? NO! Cocoon! ... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
On Mon, 7 Jan 2002 04:14, Geir Magnusson Jr. wrote: BTW, do you know they use Velocity for something??? Who, POI? Cocoon have a VelocityGenerator (the first stage in their XML transformation pipeline). -- Cheers, Pete -- you've made a dangerous leap right over common sense, like some kind of metaphysical Evil Knievel -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: On unity and coherence [was Re: [Request For Comment]POI@apache]
Answer inline -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 3:53 AM ... I can not express this POV better than Linus did in posts reported by this article: http://kerneltrap.org/article.php?sid=398 Any corporation organizizes things and I do not see better user understanding there. My viewpoint is a bit different then Linus on some things. Keep in mind that Linus does not favor complete anarchy, as is obvious from the grip he has on Linux. Yes. Linus has different beliefs in release management. I'm a bit more disciplined in style. Don't get me wrong, Linus is like my idol and all, just I bet I'm far more likely to do a sequence diagram or write documentation. We have different viewpoints on a lot of different things. Yet I don't care to maintain as tight of control over POI. I'd exert my say if say someone wanted to do the equivalent of maybe embed X inside the kernel (like the whole thing) directly, but mostly I don't try to direct things quite as much in some areas. The point is that too many restrictions are bad. The problem is to find out what too many is. IMO, things can be improved but the main problem is not lack of rigid discipline. true, I wasn't meaning to say rigid discipline would. As an example of too many or too less restrictions, I believe that: - forcing every project to follow the same code conventions would be counterproductive; Completely and TOTALLY agree. - forcing each project to have explicit code conventions and follow them would be just fine. As long as those projects can have explicitly lax coding conventions in places where others would be more rigid. (POI - write good code. be self consistent and we all kinda agree that embedded ternary operators is the most evil sin of all) It is good to have diversity. There is the cross pollination effect and there is also the fact that what one group things is better is not so sure that it should be imposed. +1 Besides, there is no such thing as an Open Source external customer. Those that contribute to it (the authors and even noisy guys like me) ARE the customers. People PAY Open Source by participating. If something is wrong FIX IT! I don't completely agree with you on that. Some contributions to Open Source are less quantifiable than others. I see I'm a bit morecommunistic. I'm so far the the left on this that I'm on the right? I doubt you are that different. *Looks down at his cookie monster slippers* is not withing to POI's mission, that won't fly. (There will be NO GUI components in POI)... If they feel like working on a feature that I just don't think is in our critical path...go at it. So, you try to keep people happy but you are not so communistic that you make everybody happy (which would be crazy, I agree). Which reminds me of an Abe Lincoln quite. Anyhow I contributed ideas. Take them for what they were. They were NOT complaints. Apache is the most healthy opensource group there is. (its healthier then GNU IMHO) I also believe so, of course. You probably know what I am talking about since POI is Open Source. POI is opensource, there are some differences of opinion between you and I on who the contributers are. To me: User: doesn't submit patches, but uses the software. The more people who USE POI the better and healthier POI is. For example. A user the other day sent a bug. He had an toasted XLS file. It had confidential data in it so he couldn't contribute a sample. I talked him through running HSSF through a debugger and he found the problem. HSSF 1.0.1 can't handle cells with strings over 15,000 characters long if they don't occur early in the file. (there is a static string table and it is kinda blocked or paged). You are talking about users that contribute something to the projects: they test it, report problems and help making it more solid that way. I still do not see any difference in your opinion. Gotcha. It often does not seem that many agree with this viewpoint. In my posting I even including this paragraph: Besides, there is no such thing as an Open Source external customer. Those that contribute to it (the authors and even noisy guys like me) ARE the customers. Noisy guys like me means I only contributed a couple of patches but I still like to think that the some of the ideas I dumped on Jakarta lists are worth something (hey, some of them did result on something besides flames). +1 Gotcha. I missed your meaning before. One way or the other, I am involved. I am NO external customer. Even if many times just with ideas, I try to influence and contribute to the evolution of the products I use. yup. And when I see no possibility of changing the product in the way it suites my needs, I fork and still save a lot of work. Like I said. I see the fork as something to generally be avoided unless there is
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Stefano Mazzocchi wrote: In my mind, all this long trail of thoughs yields the following equation: metacommunity size * community coherence * individual freedom = constant in result, if we unify the two projects, we double the size of the metacommunity and we must pay the price of decreased coherence and/or decreased individual freedom. So, if we half the community size we double the coherence and/or individual freedom? What happens if we half it again? Hmmm. I guess the optimum community size is 1. Reductio ad Absurdum I think this equation misses the important second order affects of collaboration. My feeling is that communities need a critical mass, as do meta-communities. I'm not sure what that size is, but in my mind the XML project has not reached it. And it is not just size that is the issue, it is the presence (or lack) of people who cross pollinate ideas. Within Jakarta, this is being done on an ever increasing scale. Perhaps a metric that would be more useful is to contemplate the size of the intersection between the subscribers to any two mailing lists picked at random. Without looking, it is clear to me that however you choose to quantify this metric, Jakarta would greatly exceed XML. What you have observed lately has been a spike of activity on the general mailing list. One thread dealt with the ever popular coding style issues (which unfortunately overwhelmed the more important underlying issue that Jon was trying to get us to face). The other thread dealt with the intentionally high threshold that we have for accepting new Jakarta projects. Now for a thought experiment: if POI were added to Jakarta, would this metric overall increase or decrease for Jakarta? If POI were added to XML, would the metric overall increase or decrease? Ignoring the fact that the following are clearly related, which is more important: community coherence or mission coherence? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
At 10:40 AM 1/5/02 -0500, you wrote: I would also like to personally commend Jon with his efforts to better document Jakarta. He has put a lot into the Web site (probably 90%), and we all owe him a great debt. -Ted. Despite Jon's candid remarks, as you put it, Ted, I too would like him to know that I join a throng in saying thanks. - Micael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Hello, Each structure has a cost depending on his level of organization. I think there is today to many project in the jakarta and the xml project. I feel confuse about finding the right information at the right place. And I think it's high time to merge xml and jakarta. The way java is organizing code in package is rather simple and efficient, maybe organizing project this way is the solution. We should debate about this organization. I propose some package organization : XML(Xerces,Crimson) XSL(Xalan,FOP) SVG(Batik) WebApps(Cocoon, JetSpeed...) JSP (TagLibs) FrameWork(Turbine, Avalon, Struts..) Project Management (Ant, Slide) Metric Testing (Log4J, WatchDog) ToolBox(ORO, RegExp, Lucene) ... I'd like your opinion about it, which package with which existing project. Ciao Chris - agitateur depuis toujours *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
At 15:31 05.01.2002 +0100, Stefano Mazzocchi wrote: [Snip] In my mind, all this long trail of thoughs yields the following equation: metacommunity size * community coherence * individual freedom = constant This equation is misleading. Coherence and individual freedom are not inversely proportional, perhaps related but not inversely proportional. That much is certain. in result, if we unify the two projects, we double the size of the metacommunity and we must pay the price of decreased coherence and/or decreased individual freedom. But are we sure the pros outweight the cons? No, we can't be sure. The experiment cannot be undone and started over. Anyway, contrary to my previous hints, I am unsure if having XML and Jakarta would benefit either Jakarta or XML. If someone cares enough about a particular XML project nothing keeps him/her from participating in that project. IMHO, XML does not and will never have a community as long as two of its most important projects directly compete with each other. The success of one is related with the failure of the other. XML Community? Won't happen in a million years. How the did Crimson become an Apache project anyway? Unity and coherence (the subject of this thread) are strongly related to management and decision making. Since we don't have a manager, we must have a healthy decision making process. The current system of voting where each participant is granted veto power is a system geared towards non-decision making. This was perhaps one of the intentions of the founders of the ASF. Anyone know where -1 tradition came from? My suggestion is institute a new tradition where members of the community can make proposals which the community votes on. Advantages: decisions can be made. Disadvantages: decisions can be made. The required majority for the adoption of proposals can be simple or qualified. Even if the qualified majority is 3/4, this would be better than the veto system we have today. Although a veto can be overridden by a 3/4 majority, as far as I know, this has never happened in the past. Today someone voting -1 means end of discussion. I dare anyone to -1 that. Regards, Ceki -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Chris, I think you are confusing project categorization with project community. These things are very much unrelated. Regards, Ceki At 23:44 05.01.2002 +0100, you wrote: Hello, Each structure has a cost depending on his level of organization. I think there is today to many project in the jakarta and the xml project. I feel confuse about finding the right information at the right place. And I think it's high time to merge xml and jakarta. The way java is organizing code in package is rather simple and efficient, maybe organizing project this way is the solution. We should debate about this organization. I propose some package organization : XML(Xerces,Crimson) XSL(Xalan,FOP) SVG(Batik) WebApps(Cocoon, JetSpeed...) JSP (TagLibs) FrameWork(Turbine, Avalon, Struts..) Project Management (Ant, Slide) Metric Testing (Log4J, WatchDog) ToolBox(ORO, RegExp, Lucene) ... I'd like your opinion about it, which package with which existing project. Ciao Chris - agitateur depuis toujours *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Ceki Gülcü wrote: IMHO, XML does not and will never have a community as long as two of its most important projects directly compete with each other. The success of one is related with the failure of the other. XML Community? Won't happen in a million years. How the did Crimson become an Apache project anyway? Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and Crimson. The developers *are* working together. I won't pretend that everything is 100% smooth sailing, but significant progress is being made. The required majority for the adoption of proposals can be simple or qualified. Even if the qualified majority is 3/4, this would be better than the veto system we have today. Although a veto can be overridden by a 3/4 majority, as far as I know, this has never happened in the past. Today someone voting -1 means end of discussion. I dare anyone to -1 that. Regards, Ceki The rules you describe don't look familiar to me. The ones I am familiar with are: http://jakarta.apache.org/site/decisions.html http://jakarta.apache.org/site/management.html - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
At 18:02 05.01.2002 -0500, you wrote: Ceki Gülcü wrote: IMHO, XML does not and will never have a community as long as two of its most important projects directly compete with each other. The success of one is related with the failure of the other. XML Community? Won't happen in a million years. How the did Crimson become an Apache project anyway? Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and Crimson. The developers *are* working together. I won't pretend that everything is 100% smooth sailing, but significant progress is being made. Point well taken. The required majority for the adoption of proposals can be simple or qualified. Even if the qualified majority is 3/4, this would be better than the veto system we have today. Although a veto can be overridden by a 3/4 majority, as far as I know, this has never happened in the past. Today someone voting -1 means end of discussion. I dare anyone to -1 that. Regards, Ceki The rules you describe don't look familiar to me. The ones I am familiar with are: http://jakarta.apache.org/site/decisions.html http://jakarta.apache.org/site/management.html My mistake. I was always under the impression that new project creation required a 3/4 vote *and* no binding vetoes (which I admit makes no sense). Thanks for the clarification. Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
on 1/5/02 3:02 PM, Sam Ruby [EMAIL PROTECTED] wrote: Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and Crimson. The developers *are* working together. I won't pretend that everything is 100% smooth sailing, but significant progress is being made. Yea...just like Tomcat 3x and Tomcat 4x...suuueee... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
Not that I should have much of a role in this discussion but I'd like to contribute some thoughts stemming from an offline discussion I had. I think this discussion is still missing the point. There are a lot of outsider articles on what is wrong with Apache these days, most of them refer to the total disinterest (by many developers in the projects) on the market meaning what do the user's actually want. I'd say this is a component. (Please take this as somewhat of an outsider who has a lot of experience with Apache work-products) (as a symptom of this: Apache is OBVIOUSLY a better Web Server, TOMCAT is obviously a better App server of sorts, and though not a apache project JBOSS is a great enterprise serverso why is IIS gaining ground despite its overall suckiness?) The second component is an overall lack of unity-of-purpose. XML.apache.org hasn't reached a critical mass and in my opinion may never because it does have unity-of-purpose and I think that is part of why Stefano recommended I approach Jakarta first. POI has a lot to contribute to XML.apache.org but it has a lot of stuff that *would* contribute more to Jakarta's purpose if it had one. This isn't a slam, hear me out. The Apache group had a unity of purpose early on. They had a product: a webserver. Everything that Apache did had something directly to do with that product. Some things were semi-independent so subgroups seemed like the best way to handle it. Java-Apache had this unity-of-purpose: Java on Apache. Well for Java on Apache you need a mod to handle that (since everything is a mod in Apache) so you get mod-jserv, of course you have a lot of things that roll in and out of that based on serverside components for developing with your java mod. But you have unity-of-purpose. (or at least for a time) What is Jakarta's mission? server side java stuff. What is your product (look at the homepage)whoa thats a big list of subprojects... Wait is ant a server side java tool? Well..kinda sorta (build server)... what kind of server-side java stuff. XML.apache.org has a few well-defined products with the main one being Cocoon. This may change slightly as the web services thing comes to a head (as the speaker coordinator for my JUG www.trijug.org I can tell you this is coming to a head) and more web-servicey things happen with XML rather than publishing (Cocoon) and maybe at that time there should be a webservices.apache.org (and webservices will expand beyond XML), but for the moment you've got real products and a unity-of-purpose. (Which parts of POI fit well into..the cocoon 2 serializers for instance and others do not) So what do most people (users) come to Jakarta for? Tomcat. Why? Go to the front page. A big rattled on list of componentsIf I don't know what I'm looking for suffice to say I won't find it. If I say Tomcat the general IT population knows what I'm talking about. (and the rest know what I mean if I say the successor to JServ) Here's my 2c worth (and unless asked its the only thing I'll contribute to this discussion): Defined unity of purpose: sever side java is now too fuzzy of a mission...what are your products and categorize them: application server (tomcat) build and development tools (ant/log4j/etc) document management and publishing (lucene, POI, etc) application frameworks (avalon, struts) The Apache brand is worth a lot. You say Linux in a corporate environment you get a dirty look (once upon a time we just said Solaris-clone and installed linux to avoid political battles ;-) ), you say Apache you get a less dirty look. (You're still a radical but IBM and Sun said you're an okay radical). Jakarta needs to do some actual PROJECT work. Go in and pull these disparate components into distributions (Redhat doesn't point you to their website to download X, and then GLIB and go try and put it together yourself...not that Jakarta should be redhat, but the point being having distributions). This helps create unity of purpose as things start going into distributions and distributions generate requirements and needs which roll into features. I think this equation misses the important second order affects of collaboration. My feeling is that communities need a critical mass, as do meta-communities. I'm not sure what that size is, but in my mind the XML project has not reached it. And it is not just size that is the issue, it is the presence (or lack) of people who cross pollinate ideas. Within Jakarta, this is being done on an ever increasing scale. I think you need to have points. Both to discussions and to work. In the POI project. Try this: submit to the poi-devel list (and Marc, Ken and the lurkers may not be monitoring so the experiment would be fair) a proposal or patch to do something obviously outside of POI's mission (crack those MS file formats right open, provide apis and XML publishing utils for those formats) I bet you you'll get a unified thanks,
RE: On unity and coherence [was Re: [Request For Comment] POI @apache]
Biting the bait: Maybe you and me are following different lists Jon. AFAIK there is cooperation between Tomcat 3x and Tomcat 4x people. I sure hope we will have a Tomcat 4 at least as nice to use as 3.3 is at the moment. I am sure that most Tomcat 3.x users will upgrade as soon as they feel confident about that being the case. It is possible that many already did it. Most 3.3 supporters have no emotional attachments to either the 3.3 or the 4.x code base. Many of us just believed 3.3 was the shortest path to a production quality Tomcat. _Maybe_ there was more people with other interests on the 4.x side. Either way, the main focus is on 4.x now and I do not see any ongoing flame wars on the Tomcat lists. Everybody wants its success. IMO it is better to stop feeding the flaming and let it die. Have fun, Paulo Gaspar -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 12:37 AM To: [EMAIL PROTECTED] Subject: Re: On unity and coherence [was Re: [Request For Comment] POI @apache] on 1/5/02 3:02 PM, Sam Ruby [EMAIL PROTECTED] wrote: Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and Crimson. The developers *are* working together. I won't pretend that everything is 100% smooth sailing, but significant progress is being made. Yea...just like Tomcat 3x and Tomcat 4x...suuueee... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: On unity and coherence [was Re: [Request For Comment] POI @apache]
Hi Andrew, Before trying to organizize too much how Open Source development works, maybe you should consider that impositions of organization and discipline could kill the Golden Eggs Chicken. I can not express this POV better than Linus did in posts reported by this article: http://kerneltrap.org/article.php?sid=398 Any corporation organizizes things and I do not see better user understanding there. Besides, there is no such thing as an Open Source external customer. Those that contribute to it (the authors and even noisy guys like me) ARE the customers. People PAY Open Source by participating. If something is wrong FIX IT! (Ok! I confess I learned this stuff mostly from Jon.) If you do not like an Open Source product as it is, contribute (fight) to change it. If most of the project owners do not let you, FORK. At least you can learn a lot and save a lot of work. You probably know what I am talking about since POI is Open Source. For complex enough software, Winston Churchill's remarks about democracy apply quite well to Open Source as we know it by rephrasing them a bit: Open Source is the worse form of developing complex software, except all those others that have been tried. ( The original Winston Churchill quote: Many forms of Government have been tried, and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed, it has been said that democracy is the worst form of Government except all those others that have been. ) Relax and have fun, organic growing works or we wouldn't be here! Paulo Gaspar -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 1:01 AM To: [EMAIL PROTECTED] Subject: Re: On unity and coherence [was Re: [Request For Comment] POI @apache] Not that I should have much of a role in this discussion but I'd like to contribute some thoughts stemming from an offline discussion I had. I think this discussion is still missing the point. There are a lot of outsider articles on what is wrong with Apache these days, most of them refer to the total disinterest (by many developers in the projects) on the market meaning what do the user's actually want. I'd say this is a component. (Please take this as somewhat of an outsider who has a lot of experience with Apache work-products) (as a symptom of this: Apache is OBVIOUSLY a better Web Server, TOMCAT is obviously a better App server of sorts, and though not a apache project JBOSS is a great enterprise serverso why is IIS gaining ground despite its overall suckiness?) The second component is an overall lack of unity-of-purpose. XML.apache.org hasn't reached a critical mass and in my opinion may never because it does have unity-of-purpose and I think that is part of why Stefano recommended I approach Jakarta first. POI has a lot to contribute to XML.apache.org but it has a lot of stuff that *would* contribute more to Jakarta's purpose if it had one. This isn't a slam, hear me out. The Apache group had a unity of purpose early on. They had a product: a webserver. Everything that Apache did had something directly to do with that product. Some things were semi-independent so subgroups seemed like the best way to handle it. Java-Apache had this unity-of-purpose: Java on Apache. Well for Java on Apache you need a mod to handle that (since everything is a mod in Apache) so you get mod-jserv, of course you have a lot of things that roll in and out of that based on serverside components for developing with your java mod. But you have unity-of-purpose. (or at least for a time) What is Jakarta's mission? server side java stuff. What is your product (look at the homepage)whoa thats a big list of subprojects... Wait is ant a server side java tool? Well..kinda sorta (build server)... what kind of server-side java stuff. XML.apache.org has a few well-defined products with the main one being Cocoon. This may change slightly as the web services thing comes to a head (as the speaker coordinator for my JUG www.trijug.org I can tell you this is coming to a head) and more web-servicey things happen with XML rather than publishing (Cocoon) and maybe at that time there should be a webservices.apache.org (and webservices will expand beyond XML), but for the moment you've got real products and a unity-of-purpose. (Which parts of POI fit well into..the cocoon 2 serializers for instance and others do not) So what do most people (users) come to Jakarta for? Tomcat. Why? Go to the front page. A big rattled on list of componentsIf I don't know what I'm looking for suffice to say I won't find it. If I say Tomcat the general IT population knows what I'm talking about. (and the rest know what I mean if I say the successor to JServ) Here's my 2c worth (and unless asked its the only thing I'll contribute to this discussion
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
Geir Magnusson Jr. wrote: It's my understanding that Apache Projects' unity of purpose is to encourage a collaborative, consensus-based development process What does that exactly mean? Perhaps Stefano's original preamble said it best http://java.apache.org/main/constitution.html Unlike other open source projects where an individual rules the project as a benevolent dictator, the Java Apache Project form is government is based on merit: everyone who deserves it get the right to vote and everyone who is able to vote participates in the ruling of the project. This kind of government helps in maintaining the project going even when core individuals leave the project or don't have enough time. The project itself is like the ancient Greek Agora idea, where everybody helps and who deserves it decide. This meritocracy allows the project to be very flexible toward people presence and allows fast and safe changes in the core group since who decides is always who is more involved and cares the most. I believe that everything else here, the projects, the subprojects, are just a means to serve the end of development by meritocracy. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI@apache]
On 1/5/02 7:28 PM, Ted Husted [EMAIL PROTECTED] wrote: I am not trying to be combative - I have watched this thread (and participated) with growing discomfort. I have to say that I think that bringing XML and Jakarta together might destroy the thing we are supposedly trying to 'save' (again, I don't get the problem...), namely the community that each group has. Larger isn't always better. I kinda agree with you on that. I also think we are more than ready for a POI vote, if someone were to post an actual proposal, including the list of committers. In that proposal, can it be argued why it belongs here? I have tried to sit on the fence, and I am glad Stefano will step up to champion the project, but I also think that if he scope of Jakarta is confusing now, adding a vendor-specific desktop document API (granted, with server-side uses) will add to it. There was recent talk for other clearly client projects to be added, with the same apparent quality of code and health of community - why not bundle the two as a seed for a new Apache client-focused project to be a peer to jakarta and XML and ...? If you have used any of the pure Java IDE's lately, it's clear that Java has indeed matured enough for use on the desktop, and initiatives on other client-side devices such as phones, PDA's, etc make for a very rich opportunity for Apache. Further, meta-API initiatives like Liberty which span both server and client (of all types) are clearly in Apache's interest, so I believe that a client-focused Apache project is appropriate for that reason as well. Maybe its not yet time for a vote. Let me state this again and make it very clear. POI has many users and many uses. No one I know of is using POI on the client. POI is as client-side as Tomcat is. (Tomcat is used by Netbeans a pure Java-IDE on the client!). HTML is for use on the client right? So is a library that outputs in HTML is clientside or serverside? Cocoon publishes documents that are generally read on the client right? Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html POI::HSSF reads or generates XLS files and is nearly always used on the server . OF all POI's users not one person is using it on the client. Please check out http://poi.sourceforge.net. The page describes its usage -Andy -- www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: On 1/5/02 7:28 PM, Ted Husted [EMAIL PROTECTED] wrote: I am not trying to be combative - I have watched this thread (and participated) with growing discomfort. I have to say that I think that bringing XML and Jakarta together might destroy the thing we are supposedly trying to 'save' (again, I don't get the problem...), namely the community that each group has. Larger isn't always better. I kinda agree with you on that. Ted didn't write that. I did. I also think we are more than ready for a POI vote, if someone were to post an actual proposal, including the list of committers. In that proposal, can it be argued why it belongs here? I have tried to sit on the fence, and I am glad Stefano will step up to champion the project, but I also think that if he scope of Jakarta is confusing now, adding a vendor-specific desktop document API (granted, with server-side uses) will add to it. There was recent talk for other clearly client projects to be added, with the same apparent quality of code and health of community - why not bundle the two as a seed for a new Apache client-focused project to be a peer to jakarta and XML and ...? If you have used any of the pure Java IDE's lately, it's clear that Java has indeed matured enough for use on the desktop, and initiatives on other client-side devices such as phones, PDA's, etc make for a very rich opportunity for Apache. Further, meta-API initiatives like Liberty which span both server and client (of all types) are clearly in Apache's interest, so I believe that a client-focused Apache project is appropriate for that reason as well. I also wrote that, not Ted. Maybe its not yet time for a vote. Let me state this again and make it very clear. POI has many users and many uses. No one I know of is using POI on the client. Maybe you have some marketing problems? :) POI is as client-side as Tomcat is. Why do you say that? It is used on the server side, and that's fantastic, but in my opinion (note that I recognize I am a complete outsider to your project who would be defined as a user) it seems client side. If I had a need for something like this (and I bet I will at some point), and I had the choice to look at either a) jakarta, the apache java server-side focused project or b) floccinoccinihilipilificator*, the apache java client-side project I would choose b), as I think of word and excel as a client-side thingy. No matter that my use is server-side... (Tomcat is used by Netbeans a pure Java-IDE on the client!). HTML is for use on the client right? Yep. But its a markup definition, not an API implementation. So is a library that outputs in HTML is clientside or serverside? Serverside generally, as the canonical model of HTML use is the web, with a clear delineation of server and client. However, it indeed has clientside uses - take for example any help system that outputs HTML within a monolithic desktop application. Conversely, I would argue that Excel is a totally client-side technology, and therefore a library that works with XLS files is clientside generally as the canonical model of Excel is on the desktop. However, it indeed has serverside uses Cocoon publishes documents that are generally read on the client right? Yes, but it's more than an API, right? (I don't know much about cocoon...) From what I read, POI is an API that accesses data in XLS files... Theres a huge difference. And Cocoon isn't part of Jakarta, is it? :) I don't necessarily think that xml.apache.org is the right place either, although I am not a member of that community in any way shape or form, so that opinion is worth the bits through which it was transmitted. I think that a client project peer to jakarta is still the right place, at least worth discussing, as we have the interesting temporal convergence of the proposal of multiple client side projects when java on the client side is becoming a much more interesting space to work. Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html I will. POI::HSSF reads or generates XLS files and is nearly always used on the server . OF all POI's users not one person is using it on the client. Please check out http://poi.sourceforge.net. The page describes its usage I will. Note I spent years supporting Excel 'stuff' in the financial industry as part of a project I led, and every user I knew was client-side. You may just be ahead of your time :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy -
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
Playing Devil's advocate. I think it's fair to push back on adding things to Jakarta... On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? However, you point out in the above link that the thing that makes POI special is it's ability to *write*? What's the % of mainly writing to mainly reading on the serverside? http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html Paulo might use VB to make a client side app, but I wouldn't if I wanted portability, especially if I was looking to the handheld or embedded application that could access a document remotely... http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html No comment, as it's an agreeable followup to the above. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
