Re: Undermining the Incubator
In summary: Oh of course no problems exist, its all fixed and happy. Just don't mind the dead bodies floating in the pond. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: community@apache.org Date: Mon, 12 Jan 2004 23:21:50 -0500 To: community@apache.org Subject: RE: Undermining the Incubator Andrew C. Oliver wrote: I suggested that Blojsom might be a good choice for hosting ASF project news and might also make a great ASF project as I know the author is already indoctrinated I didn't say it would be a good project for the incubator. The Incubator is how projects get into the ASF. I think the incubator is the #1 worst problem of the ASF presently. Two things reduce the effect of your statement: 1. The fact that your complaints demonstrate a lack of awareness regarding the current Incubator. 2. The fact that your proposal essentially outlines how the Incubator *does* work. We'll get to the latter shortly, but first ... The Incubator exists for the purpose of importing codebases and projects into the ASF. There are basically three cases: (a) an externally developed codebase intended to go into an existing project (b) an externally developed codebase intented to become a project within a PMC (c) an externally developed codebase intended to be a new TLP In the case of the (a), we need to clear the IP. The Incubator STATUS file provides an outline and diary for doing so. The Community issues are addressed because the code is going into an existing project. In the case of (b), we need to clear the IP, and ensure that the project has a viable community. Again, the STATUS file has the guidelines. Lastly, in the case of (c), we need to clear the IP, ensure that the project has a viable community, and that the community is ready to take its place as a TLP. In all cases, decisions are made by a group made up of the Incubator PMC, the project's committers, and the destination PMC (if any), and known as the PPMC. That is one group directly empowered to manage that project's decisions, reporting through the Incubator, and collaborating together as peers. When the PPMC decides that the project is good to graduate, based upon fulfilling the necessary criteria, it is done. Now, since I know that you had a bad experience with the old form of the Incubator, let's first address your complaints compared to the way things work now. It doesn't legally protect the ASF. The Incubator ensures that the proper paperwork is done regarding CLAs, code grants, etc., are filed. Something that the other projects failed to do consistently enough to result in the Incubator's formation. Ideally, the Incubator provides a focus and location, and the project(s) interested in the code perform the due diligance, but the process ensures that it gets done. * Exposes the Foundation to undue legal issues by protecting projects PRIOR to their legal issues being sorted out. As opposed, for example, to exposing the Foundation to undue legal issues when projects import codebases directly into releases without permission from either the Foundation or the author? That is one of the things the Incubator exists to prevent. In any event, only the Board should, and can, talk authoritatively about legal protection afforded by the ASF. * Has a high potential to create a dead project zone over time (but this I guess we'll see) as we give hosting and a fuzzy idea with many different opinions on when a project gets out or not. In actuality, one purpose of the Incubator is to help prevent non-viable projects from becoming ASF projects, and to help projects become viable, when possible. We have a pretty good opinion as to when a project gets out or not. It is embodied in the STATUS document, and in the minds of the PPMC, which would vote for the project to graduate. * Has a number of people not involved in the project sitting roost over the project. The Incubator doesn't work that way. The people involved in the project are directly involved in the project's management. Ask the members of the Spam Assassin PPMC, the Geronimo PPMC or the Directory project whether or not there are a number of people not involved with the project sitting roost over them. * Hurts already healthy communities by putting them back into an alphaish state. Healthy communities with clean codebases are not intended to stay within the Incubator. Projects in the Incubator are there because
Disregard Re: Undermining the Incubator
The Send button is near the close button. I missed. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: community@apache.org Date: Tue, 13 Jan 2004 01:34:55 -0500 To: community@apache.org community@apache.org Subject: Re: Undermining the Incubator In summary: Oh of course no problems exist, its all fixed and happy. Just don't mind the dead bodies floating in the pond. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: community@apache.org Date: Mon, 12 Jan 2004 23:21:50 -0500 To: community@apache.org Subject: RE: Undermining the Incubator Andrew C. Oliver wrote: I suggested that Blojsom might be a good choice for hosting ASF project news and might also make a great ASF project as I know the author is already indoctrinated I didn't say it would be a good project for the incubator. The Incubator is how projects get into the ASF. I think the incubator is the #1 worst problem of the ASF presently. Two things reduce the effect of your statement: 1. The fact that your complaints demonstrate a lack of awareness regarding the current Incubator. 2. The fact that your proposal essentially outlines how the Incubator *does* work. We'll get to the latter shortly, but first ... The Incubator exists for the purpose of importing codebases and projects into the ASF. There are basically three cases: (a) an externally developed codebase intended to go into an existing project (b) an externally developed codebase intented to become a project within a PMC (c) an externally developed codebase intended to be a new TLP In the case of the (a), we need to clear the IP. The Incubator STATUS file provides an outline and diary for doing so. The Community issues are addressed because the code is going into an existing project. In the case of (b), we need to clear the IP, and ensure that the project has a viable community. Again, the STATUS file has the guidelines. Lastly, in the case of (c), we need to clear the IP, ensure that the project has a viable community, and that the community is ready to take its place as a TLP. In all cases, decisions are made by a group made up of the Incubator PMC, the project's committers, and the destination PMC (if any), and known as the PPMC. That is one group directly empowered to manage that project's decisions, reporting through the Incubator, and collaborating together as peers. When the PPMC decides that the project is good to graduate, based upon fulfilling the necessary criteria, it is done. Now, since I know that you had a bad experience with the old form of the Incubator, let's first address your complaints compared to the way things work now. It doesn't legally protect the ASF. The Incubator ensures that the proper paperwork is done regarding CLAs, code grants, etc., are filed. Something that the other projects failed to do consistently enough to result in the Incubator's formation. Ideally, the Incubator provides a focus and location, and the project(s) interested in the code perform the due diligance, but the process ensures that it gets done. * Exposes the Foundation to undue legal issues by protecting projects PRIOR to their legal issues being sorted out. As opposed, for example, to exposing the Foundation to undue legal issues when projects import codebases directly into releases without permission from either the Foundation or the author? That is one of the things the Incubator exists to prevent. In any event, only the Board should, and can, talk authoritatively about legal protection afforded by the ASF. * Has a high potential to create a dead project zone over time (but this I guess we'll see) as we give hosting and a fuzzy idea with many different opinions on when a project gets out or not. In actuality, one purpose of the Incubator is to help prevent non-viable projects from becoming ASF projects, and to help projects become viable, when possible. We have a pretty good opinion as to when a project gets out or not. It is embodied
Re: Undermining the Incubator
Except that it is not. I just think I'll bring it up in 6 months when there are more dead bodies floating around. Noel does a great PR job though. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Steven Noels [EMAIL PROTECTED] Reply-To: community@apache.org Date: Tue, 13 Jan 2004 08:58:35 +0100 To: community@apache.org Subject: Re: Undermining the Incubator On Jan 13, 2004, at 7:48 AM, Noel J. Bergman wrote: In summary: Oh of course no problems exist, its all fixed and happy. Just don't mind the dead bodies floating in the pond. In other words, because there were problems before it was fixed, it doesn't matter if it is fixed now or not? Yeah, and if we consider it fixed we don't have anything to rant about anymore. :-| /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - 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: Undermining the Incubator
From: Rich Bowen [EMAIL PROTECTED] Reply-To: community@apache.org Date: Mon, 12 Jan 2004 21:24:49 -0500 (EST) To: general@incubator.apache.org general@incubator.apache.org Cc: community@apache.org community@apache.org Subject: Re: Undermining the Incubator On Mon, 12 Jan 2004, Andrew C. Oliver wrote: Okay Rich, I'll take you up on one. I don't feel like digging up the stuff I've noted on the JCP so lets talk about the incubator. First of all, thanks for this thorough resonse. Sure. True. This does belong on community@ Problems: * Exposes the Foundation to undue legal issues by protecting projects PRIOR to their legal issues being sorted out. Perhaps I misunderstood something somewhere. This is certainly not the intention, and if that is happening, I agree that this is a Bad Thing. The intent, as I understand it, is not to extend this kind of protection until they have graduated. However, I must defer to the Board and the Lawyer Types on this point, as I am utterly ignorant of the actual legal aspects. If the folks have signed the code over to you via CLAs and you are serving it from Apache servers, is not the foundation liable? So if they violate licenses and contracts prior to us certifying that they aren't but we've already accepted the project it is not legal rocket science. Oh its not my stolen car, I've already signed the contract and its on my property but I'm just considering buying it * Has a high potential to create a dead project zone over time (but this I guess we'll see) as we give hosting and a fuzzy idea with many different opinions on when a project gets out or not. Yes, I can see that as a potential problem. We need to be vigilant to not become sourceforge. A firm policy about jetisoning projects that are not making active progress towards graduation might be in order. I just favor not accepting them at all until they've done their work. * Has a number of people not involved in the project sitting roost over the project. The folks that are sitting roost are interested in very specific things. While I agree that a member of the community may be better able to determine whether it is a vibrant and sustainable community, it seems very evident that it necessary for an external party to be involved in the verification of the code legality. Audits *must* be done by external, disinterested parties for them to be of any credibility. So it would seem that this is both good and necessary. Do you see these audits happening? Now, if the folks that are involved in this process are indeed sitting roost rather than mentoring or coaching, then I could see that this is a problem. Once again, this requires careful oversight and vigilance to ensure that this doesn't happen. But I don't see this as a condemnation of the process, so much as something that needs to be carefully monitored. That¹s already happened on a number of occasions (you can read the archive for numerous hey what the heck are you guys doing other than yacking about status files and process). Now that it has been monitored now what? * Creates confusion. Most people will believe the project is an Apache project at the point of incubation. Yes, agreed. And I can see this contributing to the perception of your first point regarding legal protection. And it weakens Apache as a brand. It brings us all down. * Hurts already healthy communities by putting them back into an alphaish state. I just don't see this. Can you elaborate on this? We're verifying that they have certain qualities, not claiming that they don't. Sure. If I had a mature project ready for production which had been so for a number of years and then I said I want to be part of Apache You'd put it in the incubator and tell the world it needed incubation? Pretty ugly perception that pushes about a mature project. Solution: * Disband the incubator. Not to give any false impressions, I should be very clear that I don't agree with you on this point, and, based on your following comments, I'm not sure you do either. Sounds like you want some pretty significant changes, but that you still want some process in place. Seeing as I don't give a damn what it's called, if you want to call it candidating, or something else, it's all the same to me. I think that a process needs to be in place, and it needs to address certain issues. What it gets called is of no consequence to me. Next, it's possible that I've misunderstood some details at some point, but it does not seem that your recommendations are so very far from what is in place. No place, leave the project where it is until it has proven it meets the requirements. Yes they are, and they have not changed much since before the incubator was created. * To propose the vote a project must prove that all CLAs are turned in and a license audit has been performed under the supervision of the said sponsoring
Re: Undermining the Incubator
So, like I said, I clearly missed what you suggested as fixes to the problems that you perceive. While I'm sure that this discussion belongs on the incubator list, rather than here, I have a strong suspicion that you're going to respond with a note to the effect that you've already been through this and don't want to again. Okay Rich, I'll take you up on one. I don't feel like digging up the stuff I've noted on the JCP so lets talk about the incubator. Hopefully you don't mind me quoting that much publicly, if so I apologize. I feel this should take place on community@ as its a question on whether the incubator is serving the interests of the foundation and should exist at all. Seems kind of funny to discuss should this thing be here there. Problems: * Exposes the Foundation to undue legal issues by protecting projects PRIOR to their legal issues being sorted out. * Has a high potential to create a dead project zone over time (but this I guess we'll see) as we give hosting and a fuzzy idea with many different opinions on when a project gets out or not. * Has a number of people not involved in the project sitting roost over the project. * Creates confusion. Most people will believe the project is an Apache project at the point of incubation. * Hurts already healthy communities by putting them back into an alphaish state. Solution: * Disband the incubator. * A project must have at least sponsoring MEMBER willing to go join the project and help them adopt the voting rules, document legal issues by performing an audit * A project's acceptance is governed by a PMC accepting it or the members voting to create a TLP. This should be ratified by the board who should have veto power. * To propose the vote a project must prove that all CLAs are turned in and a license audit has been performed under the supervision of the said sponsoring member/members. * prior to the project's acceptance into Apache it has no Apache status (legal/otherwise). I suppose we could give it a candidate logo. This: * Protects the foundation * Makes the responsible people responsible and less help from the peanut gallery. * Makes members responsible. * Gives the acceptance to the project and the people accepting it. No more tricameral votes. Issues: What about how things were before?? The incubator sought to solve what was essentially a communication issue via more process. I suspect it was also created (I read this in emails by some of its proponents and Sam replied that¹s not what I voted for as a board member or something to that effect) originally as a flood gate to slow or prevent the growth of Apache. I think the communication issue (about oversight) has been solved. In fact I rather thing we've gone a little too far in the other direction. Some projects are just lazy and haven't done their auditing. Other projects are more vigilant. I think this is normal. What could be done about it I don't know for sure but the incubator doesn't further that, maybe the PMCization thing did, but I think moving the responsibility down the latter will do more, then some manner of accountability (dirty word I know in a volunteer organization). The incubator was also supposed to help projects obtain their base resources. What is really needed here is a request tracker for the infrastructure project (which should become more of a project and less of well what it is but that is a rant for another day). To reduce contention and further compromise, I support grandfathering. I'm not going after Geronimo. Let me go on record, I do not hate Apache or the whole institution I just think some of the decision made over the past year or so have been in conflict with the letter if not the spirit of the open in open source. I also want to help people in, not force them out. I think Apache has its place, of course we all have different opinions on what that is. -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Location for syndicated Apache blogs
Unrelated to whether or not we would use it, I think that blojsom could be a very nice ASF project. From what I have seen of it, I'd support its entry to the Incubator. --- Noel Hahaha...Suffer the incubator! *evil laugh* Does it seem sensible to take an already successful ASL licensed, community developed piece of software by an already successful open source developer and force it into a somewhat beta status by making it go through the incubator just because that is the way things are done? -andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: community@apache.org Date: Fri, 9 Jan 2004 21:35:04 -0500 To: community@apache.org Cc: [EMAIL PROTECTED] Subject: RE: Single Location for syndicated Apache blogs It is possible that he'd be willing to [bring blojsom] to the incubator. It already has a very active community. Its probably bordering on becoming a standard just because Roller tends to take Blojsom's code. Unrelated to whether or not we would use it, I think that blojsom could be a very nice ASF project. From what I have seen of it, I'd support its entry to the Incubator. --- Noel - 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: Single Location for syndicated Apache blogs
It is a good idea. That being said the author of Blojsom (http://blojsom.sourceforge.net/index.html) is a rabid ASL/BSD license freak. The structure of Blojsom is such that it could possibly be sticky glue for other technologies, meaning writing a Cocoon plugin for it shouldn't be too hard. It is possible that he'd be willing to undergo the water torture and pickling process that is the incubator. It already has a very active community. Its probably bordering on becoming a standard just because Roller tends to take Blojsom's code. Secondly, it is *simple*, file-based and borders on moronically simple (like bloxsom). Lastly, it seems like http://blojsom.sourceforge.net/plugins/index.html someone could write a subversion plugin and then you could even use it to hold the content. Having this form of aggregate project news is a pretty sensible step. It also reduces some of the overhead in constructing the Apache Newsletter, increases the chance that our release/project news will be syndicated across the web and other various benefits. Lastly, I can vouch for the performance. I was slashdotted awhile back and blojsom lived. At the same time, the radio and roller blogs which were also slashdotted went down. In fact, my server CPU usage never topped 10% above normal (and my server is a PIII-733mhz running Linux!) and the site stayed responsive. Its only slightly more overhead than html so hardware is really not a concern. -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: community@apache.org Date: Thu, 8 Jan 2004 15:40:29 -0500 To: community@apache.org Subject: RE: Single Location for syndicated Apache blogs Ok, I'm quite happy to register and host planetapache.org; whether or not we want to point it at minotaur is more or less irrelevant I think, but I'm open to argument either way. :-) Personally, a useful application of this technology would be to provide projects with a means to publish news in a format that we could aggregate on the site, and perhaps make use of for the newsletter. A blog and content syndicator for use as an internal ASF news service would be a good thing. At least two projects, WS (http://ws.apache.org/blog/) and POI (http://nagoya.apache.org/poi/news/), already have project blogs, although using different technologies. I would certainly support project blogs using some standard technology. I'd like to see us eat our own dogfood, and encourage projects to contribute that way. We could see what projects like Cocoon/Lenya, Jetspeed/WSRP4J, etc., might offer in combining their technologies in some manner. --- Noel - 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: Policy for Jakarta Wiki(s)
*snip* (I don't care to discuss everything privately on the infrastructure list so we can agree to disagree -- we can agree that community@ is not perfect and I don't subscribe to infrastructure) disagree :D. I think manual namespacing with long wiki names is more of a pain. It's a preference thing. So how is someinterwikithing:blabla different? I just want it on a header somewhere that people can see it, otherwise the wikis won't link at all and that will suck pretty bad. Ideally we'd have: [blabla] == blabla wherever it is found. If there are TWO blablas then it would go to a blabla is here - [cocoon:blabla] and here [tomcat:blabla] but if you did [cocoon:blabla] it would link directly to cocoon. Same deal as interwiki links but allows crosslinking to be easy while preserving non-cross linking too. Not that it is possible. I just think we're fragmenting the hell out of everything in general (web pages, wikis, mail lists, etc) and pretty soon Apache will be a big mess of spaghetti if it isn't already. I mean I couldn't begin to explain to someone where to find something at Apache, I just type the link for them that I've memorized... Our web information is truly a jumble of mess. I'm not trying to be inflammatory if its coming off that way, its just I deal with a lot of normal people and we get out the message pretty poor because we try and make the user learn how Apache is organized just to find a webpage. I guess my point has degraded...I'll stop. I just think things should be flatter and more easily located. Planet too. -Andy cheers! - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy for Jakarta Wiki(s)
That¹s fine, but the results aren't very useful see this: http://wiki.apache.org/general/FindPage?action=titlesearchvalue=FAQ This is what I mean (across wikis): http://nagoya.apache.org/wiki/apachewiki.cgi?search=FAQdosearch=1 The main issue I have with splitting things up are search and linkage. I have no objections otherwise (supposing someone else has the headache of dealing with 100 different wiki configs). Also consider this: http://nagoya.apache.org/wiki/apachewiki.cgi?search=AvalonFAQ I can find out what pages are linked FROM as well as TO. Its unfortunate no wiki supports namespaces of a sort. -Andy On 12/10/03 6:42 AM, Leo Simons [EMAIL PROTECTED] wrote: done: http://wiki.apache.org/general/FindPage newly created wikis will have the search box by default. Even did the neat google customization trick. - LSD Jason Dillon wrote: Why not add a google wiki search over wiki.apache.org? --jason On Dec 9, 2003, at 8:22 PM, Noel J. Bergman wrote: Andrew C. Oliver wrote: we should not loose search and cross linking capabilities. I really want to throw my support behind wiki.apache.org but it doesn't support this which makes Apache look like such an opaque spider. This is the first that I recall hearing such comments from you. Don't you think that you should air your concerns to the folks working on the Wiki? What is wrong with interWiki links for your second item? --- Noel -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Way cool
This is so cool: http://nagoya.apache.org/wiki/apachewiki.cgi?WikiBrazil Whomever did that...keep it up. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization project
, both WRT translation efforts and WRT crosspollination, as these kind of people will see beyond their small project(s). Also, it oculd bring new kinds of developers (Today I heard in the radio, coming home, that 72% od people in Spain cannot speak *any* foreign language. We are a bad sample but in most of Europe, less than 50% people speaks English.) The problem is that I can't see clearly how to implement such a crosscutting service/project, in ways that would not be difficult to impossible to manage. Specially since we should keep source control on both the original doc and the translations in sync. Any ideas? Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sun and the JCP 2.5
Please read this: http://openenterprisetrends.com/cgi-bin/page_display.cgi?193 Does anyone know why JBoss isn't being granted the scholarship? I read the Happiness is here today JCP 2.5 announcement (http://java.sun.com/features/2002/10/new_jcp.html) again and it says qualified achedemic, non-profit and opensource members. While I realize that this isn't an Apache opensource project, it was my understanding that Apache had invested a great deal of effort in getting Sun to open up the JCP and enact these reforms. I would hate to thing and be very disappointed if they were not being applied fairly. Who is on the current scholarship board? Any apache folks? Are you able to comment? Thanks, -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun and the JCP 2.5
Yes, Apache is on the scholarship board. If you want to discuss this further, you might consider joining the [EMAIL PROTECTED] mailing list. The problem is that I might inadvertantly receive information covered by apache's non-disclosure agreements with Sun. This could limit my economic viability in the future should I wish to implement a technology which competes with Sun. Would it be possible to have a list set up for those who are either not members or whom do not wish to be bound by such agreements to discuss the Apache side of the JCP? -Andy - Sam Ruby - 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: Sun and the JCP 2.5
I've suggested this time and again, making a jcp-discussion list where no NDA-covered information would be submitted, but there never is any interest. Okay. If you are interested now - Sam, could you do the honors? +1 geir -Andy - Sam Ruby - 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: Sun and the JCP 2.5
We've been through this before. The list is has no Sun employees on it. It has only Apache members. They make decisions on behalf of the ASF. You can choose to no longer be a member of the ASF. You can choose not to participate. At the moment, you have chosen the former and not the latter. Sam, I've gotten rather disappointed with your tactics of late. I choose to take part in the ASF and its decision making processes. I choose not to have information that would limit my financial viability via making me party to a Non Disclosure Agreement. I'd like to avoid a situations such as say someone posts some NDA'd spec for a VM as part of some JSR you're working on and I then go and start working on Mono and Sun takes my house for disclosing.. (possibly without me even reading it) I wanted to raise a legitimate question (thanks to Roy for a USEFUL answer) and from you I keep hearing it puts the lotion in the bucket or it gets the hose... I think an open JCP list where no NDA material is permitted would be entirely appropriate. -Andy -Andy - Sam Ruby - 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] SuperXMailer
Ben, You're being obstructionist. Lets not make this into a big political thing. Its important that Apache have a mass mailing solution and its great community project. We're even going to advance the state of development through extensive use of UML, implement the CMM and utilize the grand System Development Lifecycle methodology. This is going to be big! I'd like to see more support from you on this! -Andy cc: community (see SuperXMailer proposal: http://article.gmane.org/gmane.comp.jakarta.general/4289 ) PS: eyebrowse archive of [EMAIL PROTECTED] is busted again. bah Ben Hyde wrote: No way, not until the board clarifies project's reply-to header policy. On Tuesday, April 1, 2003, at 03:35 PM, Andrew C. Oliver wrote: GREAT! Add yourself as a committer to the wiki page! I'm glad there is so much community enthusiasm for this! Ben Hyde wrote: +1, I'm seriously considering doing an Ada port! On Tuesday, April 1, 2003, at 03:03 PM, Andrew C. Oliver wrote: Hi All, I'm pleased to finally propose the SuperXMailer for Jakarta via the incubator. I'd like for the Jakarta PMC/committers to vote a tacit approval of the project before we work on acceptance into the incubator. I'm sure that despite the inevitable controversy, folks will see a true value in this project and its active community. Unfortunately the source repository and mail archives are down at the moment, but I'm sure they'll be restored soon. Note that there is also something strange with the bug database. We now have email deobfuscation which defeats schemes like [EMAIL PROTECTED] and such, as well as acoliver at apache dot org. No worries, the mail will be harvested and get through! Thanks for your consideration. Please feel free to submit your vote in advance. -Andy http://nagoya.apache.org/wiki/apachewiki.cgi?SuperXMailerProposal [0] rationale SuperXMailer, the project hosted at http://sourceforge.net/projects/superxmailer/ is a tool for harvesting email addresses from web pages and mail lists, storing them in any database or XML file, and sending them email addresses. It features opt-out lists, email verification and much more. The project is the creation of a number of Apache committers and is run as a meritocratic community-developed project. Presently the CVS repository and mail lists are down (as of 3/30), but we have opened up a support request and will have it up again soon. [0.1] criteria Meritocracy: SuperXMailer follows the Apache meritocracy rules, with a core of committers including ASF members. Community: SuperXMailer has a modest, but very active community. Its users are very pleased with its performance and capture capabillities. Core Developers. SuperXMailer has an active and dedicated team of committers. The project was founded by Andrew C. Oliver, who is extremely dedicated to SuperXMailer and authored the majority of the codebase. Nicola Ken Barrozzi and Glen Stampoultzis are frequent contributors of components and bug fixes as well as some significant extensions. Sam Ruby has offered to provide Web Services extensions via Axis. Alignment: SuperXMailer makes use of Lucene, POI, Struts, Velocity, Turbine, Xerces, Tomcat and Xalan. Scope: SuperXMailer is entirely a server-side application, well aligned with the overall goals of the Jakarta project. [1] scope of subproject The project shall create and maintain packages written in the Java programming language constituting the framework, management tools, search/database and mailer, a standard library of additional components, documentation, a web site and additional examples. [2] identify the initial source from which the project is to be populated The project currently resides on the SourceForge (http://tapestry.sf.net). [3] identify the Jakarta resources to be created [3.1] mailing lists(s) superx-user superx-dev [3.2] CVS repositories jakarta-superx [3.3] Bugzilla framework - superx components - web site, contrib library, documentation, examples [3.4] Wiki The SuperXMailer developers would like to make use of the ApacheWiki in order to facillitate the admittedly spartan documentation. However, its extremely easy to use. Many Apache committers have received mail from persons using it with great results. [4] identify the initial set of committers (Any Jakarta commmitter is welcome to add their name here) Andrew C. Oliver Nicola Ken Barrozzi Glen Stampoultzis [5] identify apache sponsoring individuals (Any Apache member is welcome to add their name here) Andrew C. Oliver Nicola Ken Barrozzi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RANT: Licensing, Business models and success metrics (was Re: answer
Andrew C. Oliver wrote: This is going to be another one of my long answers to a short question... Good! (I crosspost to community. I think it really belongs there ;-) I prefer to call it the monkey house http://blogs.cocoondev.org/stevenn/archives/000769.html ;-) Specifically in server side applications. For instance, as Andy hints in my next quote, a single download from a intranet server in a big corporation can lead to tens of thousands of (unsuspecting) users. Note that its irellevant to me that they actually DO it, just for POI its relevant that they considered it. It would serve little benefit to me if they did. (No money changing hands, unlikely that they'd contribute anything back). . I for one do not seek to have tens of thousands of level 1 users. (Meaning they barely know how to work their IDE). Whether any will convert to paid consulting gigs has yet to be seen, however its not happen yet. (All gigs have come from experienced developers who recognized that gee, if I talk to my boss these guys can certainly get it done faster and cheaper since they already know the code and the subject matter). Not that I haven't TRIED to be helpful: http://jakarta.apache.org/site/idedevelopers.html. Its just that while I enjoy conducting Java training, I do not enjoy doing it via email and I prefer to get paid for it. So this is why TOO many users can be bad. (unless they are all level 2 or better -- meaning they know what the classpath is or where to stick jars in tomcat) I don't agree that it is a good metrics, since it's a crisis situation and a lot of other factors could be involved into pricing (product life cycle, etc.). Also, we are not trying to make anybody unhappy, that would be (at most) a side effect of our approach being successful. But the post goes on: This is my personal metric... I put that under personal because I want to put that unit out of business with POI and later the whole company out of business with another project I'm working on. Everyone needs a hobby right? This is mine. I have facts which back up my belief that we affected this, but I won't go into them as its not relevant. This is my non-monetary compensation.. . I can't wait to see them on www.f*ckedcompany.com. Sadistic? Maybe. However, I enjoy it. This is the point I think merits further exposure/discussion. I'm not going to flame Andy on this, since I fully agree with it. If we cannot extract actual benefits from our involvement in Apache projects, the projects will not work/scale well. Not to mention there seem to be more heated discussions... Each and everyone involved in Apache projects should benefit in terms of: * better career opportunities * being better known in the industry * having better tools in our daily work toolset * higher productivity in integration * knowing where technology is moving * __fill more here__ The Apache licensing model is oriented towards consultancy/system integration rather than product sales. This is in opposition to other licensing schemes like GNU: I disagree. The Apache licensing model is oriented towards club works or towards use by big companies. I would license a tool if I'm trying to see a standard API under such a license. (I've come to change my opinion on this). I'd probably not license say an AppServer under this license. Why? I'd want to compete with IBM and BEA and friends, not have them share or use my code. Thats what GPL is good for. * If you hold the copyright of a GNU licensed stuff, you can re-license it as closed source (a lot of GNU-licensed projects are doing this, see Aladdin or Transvirtual with ghostscript and kaffe) And I agree that licensing dollars are like crackrock. You should endevour not to become addicted to them. I think services are the revenue stream of the future.. however one should endeavour not to be too dogmatic about this. If you happen to GPL and someone wants to pay for a license so that they can embed it, then taking their money sounds like something good to do. There are limitations (how to handle contributor requests for the same) but life is a tradeoff. (you give up the restfulness of death ;-) ) * If you hold the copyright of an Apache, BSD or Artistic licensed stuff, it is far more difficult to do this, because everybody is free to do the same. This introduces an asymmetry I don't like WRT GNU licensed projects: the person transferring copyright looses rights WRT the person holding it. I don't critizise this approach with the FSF proper, but I don't like, for instance, kaffe benefiting from my patch and I being unable to benefit in the same way. yes. This is why such projects need a compensation program that guarantees the rights of contributers. Surely by one patch you shouldn't be able to embed the whole thing and sell it in Netscape Application Server^M^M^M^M^M^M^^M^M^^M^M^M^M^M^M^^M^M^M iPlanet^M^M^M^M^M^M^MSunONE
Re: [PROPOSAL] Open this list
* I will rejoin and stop whining about it. won't you consider being nice and doing that anyway? or is this the only price you'll accept? grin size=huge/ laugh/ No Chance. Not enough time on my hands these days. As for the rest... Sure then I propose we create another list open to the public and archived. Call it opencommunity or public or something. This achieves roughly the same objectives. -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Open this list
I would like to propose that after seeing the way that this list functions up until now, that it the issue be reconsidered and that it be re-opened to the public. Main considerations: * there is already a private list *committers* which important issues like gee the server was attacked, please don't leave publically executable/writable files in your home director expecially you, you and you * The quality of the conversation will increase * The dumb user who stumbles in factor is pretty low. Since [EMAIL PROTECTED] was moved to the bottom of the mail2.html page under everything else, the moron flamewars have settled. Now all the flamewars are started and run by primarily committers. * promotes community and discourages the perception that we're arrogant snobs Minor considerations: * I will rejoin and stop whining about it. -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
board hat=on in fact, until such time as a clear determination is made, i'm ruling that it is *not* allowed. it is not worth the risk. so lgpl-licensed materials in the asf repositories are forbidden until a final decision is made. /board that may seem heavy-handed and arbitrary; i apologise ahead of time, particularly if i turn out to be wrong. however, i am saying this in good faith and in an attempt to do what's right. i will welcome an official answer no less than anyone else. While I do not want to have a discussion on the matter, I would like to state my preference to have some determination on this matter in the near future. -Andy licenses are stupid and annoying, just play freaking nice Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unsubscribed...
Hi All, So the news of my unsubscription reached here before I had a chance to say it. wiki development should take place on a public mail list where everyone can participate. I suggest wikidiffs with [PATCH] in the subject. I personally think more effort should go into using the wiki than developing it, but I'l lapply patches. I no longer regard mailing lists with no codebase as a productive use of my time. I detailed that pretty well in my blog. Basically the amount of discussion as greatly exceeded the amount of action which violated my new years' resolution. Anyhow. I'm not asking for agreement. Just telling why. Have fun and good luck, Andy
Re: fyi wiki statistics
- The RSS feed doesn't present the deltas. It appears that events are getting lost. I have nothing useful to contribute to the conversation. I'm just working on fixing that... http://nagoya.apache.org/wiki/apachewiki.cgi?WikiProjectPage -Andy
Re: fyi wiki statistics
(not aimed at everyone...you're just standing in the way ;-) ) Though I must say listening to people who aren't known for writing excessive amounts of documentation debate documentation tools for people who do is extremely amusing.. Meanwhile a previously excluded documentor: http://nagoya.apache.org/wiki/apachewiki.cgi?TimOBrien Tim OBrien is ACTUALLY USING to tool we have to create actual documentation. That is the ultimate validation for the wiki. The power is he didn't have to install a buttload of software to start WORKING. I'm rather bored with gee lets talk about the perfect documentation tool rather than writing documentation and then adding features to what you have when you need them.. . Actual USE based development is the best. -Andy ...back to my cave planned contribution for the http://nagoya.apache.org/wiki/apachewiki.cgi?FlameBait page: Maybe I write doco rather than have philisophical discussions about tools because I don't have a book deal
email notification done...sorta
So I have email notification sorta working. I can't get the diffs included.. Its too bad we don't have any decent perl programmers. I'm apparently the master PERL programmer here. The rest of you are all talk. To see the error (which since I cant fix it, you all are obviously not good enough to fix) subscribe to [EMAIL PROTECTED] -jAndy.pl.NET
Re: email notification done...sorta
Andy, I'm getting quite sick of your you're all talk attitude. Chill the hell out. -g damn. I was joking around. sheesh.
Re: http://nagoya.apache.org/wiki/apachewiki.cgi?FlameBait
WTF I thought I unsubscribed from this list? http://www.freeroller.net/page/acoliver/20030108#when_is_community_not_a Danny Angus wrote: Andy, I just read http://nagoya.apache.org/wiki/apachewiki.cgi?FlameBait Danny. It was a joke. Notice the title.. Notice What are examples of... and I listed MY emails.. . Its a joke on myself...its funny...laugh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheWiki RSS feed moved into apachewiki.cgi
I requested a wiki mail list.. no response as of yet. Steven Noels wrote: Steven Noels wrote: I'm currently messing around to change the Sender: address to a non-role account address. As soon as I found out, I can send it any way you want. This is done - change notification mails are now being send as: From: Apache Wiki [EMAIL PROTECTED] ... so I can send them to any mailing list I'm subscribed to myself. I guess Perl gurus would be more useful to make the 'diff' messages a bit more interesting. This still remains to be done, and no hablo Perl over here. I only found where in the Perl script the RSS feed gets constructed, but I can't find how one could inject the diff'ed content of the page. But since this is one of the features of the Wiki script, I assume this should be possible. /Steven
Re: mailing list organizatoin (was: [VOTE] Mother may I)
+1 (There is a lot of this kind of experience and knowledge hanging around in the backs of many of your heads -- we should write it down!) ccing community as I think we're moving sufficiently off course that its best discussed there. Started it: http://nagoya.apache.org/wiki/apachewiki.cgi?MailListBestPractices Anyone who wishes to participate please feel free to edit this page. Once it becomes useful I'll create a more formal page. -Andy -aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry incubation
[1] http://tapestry.sourceforge.net [2] http://nagoya.apache.org/wiki/apachewiki.cgi?TapestryProposal Tapestry is a component-based web framework. Its created by a great group of guys whom I have a lot of respect for. Noel J. Bergman wrote: I'll bite ... what is Tapestry? --- Noel -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] Sent: Saturday, January 04, 2003 17:54 To: community@apache.org; Jakarta General List; general@incubator.apache.org Subject: Tapestry incubation no-connotation requestedaction=subscribe, ignore Please subscribe to general@incubator.apache.org if you are interested in participating in the Tapestry incubation process. Thank you, Andy /no-connotation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheWiki RSS feed moved into apachewiki.cgi
Right.. .Just this continues to be said over and over and over by primarily the same people in response to me. My repeated response continues to be http://nagoya.apache.org/wiki/apachewiki.cgi?JustDoIt because http://nagoya.apache.org/wiki/apachewiki.cgi?SomeoneElse doesn't feel like it ;-) -Andy Ben Hyde wrote: On Saturday, January 4, 2003, at 03:39 PM, Andrew C. Oliver wrote: Right, I don't object to you contributing CVS mail patches. I just am not interested in doing it myself. I'm not trying to be nasty just convey Less talk, more action -Andy I'm not asking you do do anything, in fact I'm not sure what would be better.I'm reasonably sure what's there now is dangerous from a QA point of view - at least from my understanding of how to get good quality in an open source world. Attempting to silence critiques of the work is rarely healthy. Silent communities are either very low loyalty, or very authoritarian. - ben Ben Hyde wrote: I'm enjoying this rss service, but, this is not the equivalent of CVS mail; it's more analogous to getting a daily report enumerating which files in the software were changed. While at first I thought that wasn't a big deal, now it's clear that it pretty much precludes the proof reading that makes CVS mail such an aid to quality control. - ben On Saturday, January 4, 2003, at 11:06 AM, Andrew C. Oliver wrote: Thanks to everyone who helped... The apachewikitest.cgi is now just a link to apachewiki.cgi and what was just a test is now the real thing. So for those of you who do enjoy a good RSS feed you can do: http://nagoya.apache.org/wiki/apachewiki.cgi?action=rss For those of you who prefer to receive these by email, for now you can go here: http://blogs.cocoondev.org/stevenn/archives/000608.html - 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: ApacheWiki RSS feed moved into apachewiki.cgi
If you (steven) will guide me, I will be happy to set this up. Someone with access will have to create the mail list. I will even monitor the mail list occssionally via gmane. I do not know python so if anyone wants more features they will need to submit patches. -Andy Steven Noels wrote: Ben Hyde wrote: On Saturday, January 4, 2003, at 03:39 PM, Andrew C. Oliver wrote: Right, I don't object to you contributing CVS mail patches. I just am not interested in doing it myself. I'm not trying to be nasty just convey Less talk, more action -Andy Thanks to http://www.fettig.net/projects/hep/, I can have attached-like mails being send to some mailing list. And if someone can patch the RSS feed of the Wiki so that it has more sensible content, I assume we are almost getting there. See attached mails. /Steven Subject: WikiProjectPage From: Apache Wiki [EMAIL PROTECTED] Date: Sun, 05 Jan 2003 16:53:16 - To: [EMAIL PROTECTED] RSS is out of beta http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=WikiProjectPagerevision=7 http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=WikiProjectPagerevision=7 Subject: WhyUseWiki From: Apache Wiki [EMAIL PROTECTED] Date: Sun, 05 Jan 2003 16:53:16 - To: [EMAIL PROTECTED] http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=WhyUseWikirevision=7 http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=WhyUseWikirevision=7 Subject: JMeterDevelopment From: Apache Wiki [EMAIL PROTECTED] Date: Sun, 05 Jan 2003 16:53:16 - To: [EMAIL PROTECTED] http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=JMeterDevelopmentrevision=1 http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=JMeterDevelopmentrevision=1 Subject: JamesV2Plans From: Apache Wiki [EMAIL PROTECTED] Date: Sun, 05 Jan 2003 16:53:16 - To: [EMAIL PROTECTED] Added Redirect and Bounce changes http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=JamesV2Plansrevision=13 http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=JamesV2Plansrevision=13 Subject: BestPractice From: Apache Wiki [EMAIL PROTECTED] Date: Sun, 05 Jan 2003 16:53:16 - To: [EMAIL PROTECTED] link to WikiBestPractices http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=BestPracticerevision=2 http://nagoya.apache.org/wiki/apachewiki.cgi?action=browseid=BestPracticerevision=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheWiki RSS feed moved into apachewiki.cgi
moduse[1] has email notification, enable it. The email should go to dev@pmc.apache.org and consequential discussions can go there too. The email should include a diff. The RSS is merging change events, that's a mistake. - ben [1] Moduse is venerable software. Every time I turn something on it doesn't work quite the way I was expecting. The code defends it's self, and I love Perl. If you send me patches to either the wiki source http://nagoya.apache.org/wiki/apachewiki.txt or configuration http://nagoya.apache.org/wiki/config.txt I will apply them. It sounds like you know what you're talking about. As for the RSS, I grabbed this version off the usemod wiki's patches. Most of the patches weren't in diff -u format and I'm not a real perl programmer I just play one when I need it. They use the go here and edit this version of patches which I find very frustrating. So, I grabbed a prepatched version. If I had written it, I'd have done it as you say. If you have some actual patch or script changes send them in diff -u format. I'll apply them. Its quite simple. I love applying patches. -andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ApacheWiki RSS feed moved into apachewiki.cgi
Thanks to everyone who helped... The apachewikitest.cgi is now just a link to apachewiki.cgi and what was just a test is now the real thing. So for those of you who do enjoy a good RSS feed you can do: http://nagoya.apache.org/wiki/apachewiki.cgi?action=rss For those of you who prefer to receive these by email, for now you can go here: http://blogs.cocoondev.org/stevenn/archives/000608.html -Andy
Re: ApacheWiki RSS feed moved into apachewiki.cgi
Right, I don't object to you contributing CVS mail patches. I just am not interested in doing it myself. I'm not trying to be nasty just convey Less talk, more action -Andy Ben Hyde wrote: I'm enjoying this rss service, but, this is not the equivalent of CVS mail; it's more analogous to getting a daily report enumerating which files in the software were changed. While at first I thought that wasn't a big deal, now it's clear that it pretty much precludes the proof reading that makes CVS mail such an aid to quality control. - ben On Saturday, January 4, 2003, at 11:06 AM, Andrew C. Oliver wrote: Thanks to everyone who helped... The apachewikitest.cgi is now just a link to apachewiki.cgi and what was just a test is now the real thing. So for those of you who do enjoy a good RSS feed you can do: http://nagoya.apache.org/wiki/apachewiki.cgi?action=rss For those of you who prefer to receive these by email, for now you can go here: http://blogs.cocoondev.org/stevenn/archives/000608.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tapestry incubation
no-connotation requestedaction=subscribe, ignore Please subscribe to general@incubator.apache.org if you are interested in participating in the Tapestry incubation process. Thank you, Andy /no-connotation
Re: [FYI] Cocoon Wiki
Noel J. Bergman wrote: I'd find myself very unconfortable to force the cocoon people to move into the ASF wiki (migration issues aside) since it doesn't have the appeal and the features that our current wiki does (at least to many us). Does JSPWiki v2 provide all of the features necessary to host the ASF Wiki? Does anyone really care about usemodwiki other than that it's there and it works? As far as I know, Andrew just saw the interest and *did* something about it, for which kudos are deserved. You know about Java and FreeBSD right? If someone wishes to install a different wiki that is more featureful I don't care...however they must assume the responsibility of maintaining it. Also, having a project-specific wiki helps a lot the community oversight issues that we were discussing before. In fact, we'll probably be adding direct wiki-diffs emails to the cocoon-docs@ mail list. Push notification is my primary issue with a wiki in the context of group development. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [FYI] Cocoon Wiki
Nagoya is Solaris, I'd *hope* a java based wiki should work alright there ;-) -Thom Ahh .. .yes I discovered this the other day..hadn't noticed at first. Then I noticed that I hadn't had any peculiaritiesjust quirks... Anyhow, I don't really plan to install another wiki. http://nagoya.apache.org/wiki/apachewikitest.cgi?WhyThisWiki -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [FYI] Cocoon Wiki
Noel J. Bergman wrote: You know about Java and FreeBSD right? What about it, other than that it is 1.3.1 and the build here doesn't include the JIT? Apparently there are problems with threading among other things. All in all Java and FreeBSD do not AFAIK do not seem to constitute a stable or robust environment when used together. Though I've admittedly acquired a distate for FreeBSD. I guess its better than windows, but it would not be my first choice, especially for Java apps. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RSS feed for ApacheWiki now in beta test
Invent a CPAN style method of satisfying Java dependancies, quick while you're still enthusiastic The boys at krysalis.org will probably do it eventually... Once Nick and Ken get finished with the gump symbiosis, I bet versioning and dependency resolution won't be too far behind ;-) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: RSS feed for ApacheWiki now in beta test]
Nick pretty please ;-) -Andy (actually now you have me thinking) ---BeginMessage--- ---End Message---
Re: Wiki RSS
enable tables without enabling raw html.. . that would be my first interest... Rich Bowen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 31 Dec 2002, Stefano Mazzocchi wrote: Noel J. Bergman wrote: How good a PERL coder are you? I'm *no* Perl coder whatsoever. I have spent many many painful hours working on the UseModWiki code. It seems to be very good code, but it is large and complex. I think that if I had a very specific idea of what I was trying to accomplish, I might be able to make things happen. - -- Rich Bowen - [EMAIL PROTECTED] Author - Apache Administrator's Guide http://www.ApacheAdmin.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE+EjW4XP03+sx4yJMRAsBqAKDg8fnPig2Y4fxYz9BUKcD77pvBfwCg4IGo eio28cPedEVqYYuo7McoD+U= =b9Av -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Happy New Years!!
Happy New Years everyone. I wish you well. Remember to drink excessively and if that required driving, puke in a cab not your own car. Here is my sappy perspective on 1 year of POI... http://www.freeroller.net/page/acoliver/20021231#a_year_of_poi_a -Andy
Wiki RSS was Re: Wiki, WAS: RE: Public mail, Wiki
I'm moving this discussion over to community as I think discussing this further on members@ unnecessarily excludes the rest of the Apache community. It doesn't have to be a one-person job, just like CVS commits oversight is parallelized by sending email on the mail list. What if Wiki commits were sent to the project-docs mail list? It might be a second step, a step that will provide oversight. One more note. I've got a beta test version of the wiki here: http://nagoya.apache.org/wiki/apachewikitest.cgi (its working against the same data dir as the regular wiki so just note that edits are real). I didn't enable wiki - Mail list notification because I was being conservative (WHICH mail list, and if several that might constitute a security issue...etc etc)... however this beta version will give an RSS page for any topic by simply prepending action=rss to the query string. For example: http://nagoya.apache.org/wiki/apachewikitest.cgi?RecentChangesaction=rss would give an RSS page representing the recent changes page. It doesn't yet work because it requires XML:RSS which I do not have access to install on nagoya. I requested it be installed via [EMAIL PROTECTED] so hopefully in a few days I'll be able to move this over. The point being, this technology will allow passive notification based on topic selection in a way not found on mail lists. And of course the sources to the wiki (http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheWiki) are clearly posted so anyone can patch it and enhance this capability and I'll gladly verify and apply the patches (I hate PERL and use it every day, while I don't claim to be an accomplished PERL guy I can verify and apply patches to perl code decently).. This will enable subscribe and collaborate behavior and facilitate emergence in what I think will be a very interesting and important way. Of course those blogging freaks will probably pick it up with their aggregators, but I thinks thats an acceptable risk. Thanks, Andy
Re: Wiki RSS
I'd much prefer mailing list notifications over RSS feeds. These
types of notifications shouldn't be pull. Push-based notifications
suit this problem domain far better than pull-based approaches. It
also allows archiving of the changes. (We can recreate our entire
CVS archive in the event of a castrophic failure just from the
complete CVS commit archives.)
I agree with Justin, expecially because while email is a generally
used tool around the ASF, weblog and related technologies are not as
common.
You know...One could have said that a couple years ago regarding XML
technologies... Besides.. RSS is just XML.. .. We like XML right?
Also, I think that 'page-based' RSS it way too granular.
Look at this:
http://superlinksoftware.com/cgi-bin/jugwikitest.pl?action=rss
It looks like I was wrong. . Its not per page.. Its the recent changes
syndicated as rss... I thought it was per page... ooops.
Let's just create a wiki@ mailing list and send everything there.
Have it send unified diff's in the style of our CVS mailer. -- justin
If I had to choose I'd rather prefer to send the udiffs to the various
mail lists that control their areas.
To be honest there's a fat chance you're getting udiffs. funny
requestedaction=laughThats like asking a kangaroo to shit turtles.. .
/funny
You most likely will get diffs which will match what is written to the
wiki file that will make sense.
To enable this someone needs but to submit the appropriate patches and
I'll be pleased to install them.
Think about having [EMAIL PROTECTED] with *all* CVS commits going thru, I
don't think that anybody would stand such a low signal/noise ratio and
I fear this might be happening here if the wiki takes off.
Yes... I think the wiki is set up to allow you to specify mail lists
for those. I am not convinced this is a good idea Might be a great
tool for spamming or exploiting sendmail.Could be wrong...
I'm kinda a paranoid administrator... If it were just up to me, I'd ask
someone to write a script that goes and does this in a batch based on
some rules in a cvs module (so that access was restricted)...
roles:
crontab {
bootstrap running daily/hourly/whatever
}
bootstrap.sh {
checks out latest version of myscript and its settings
runs it
}
myScriptThingy.pl/py/whatever {
reads the wiki database, sends mail notificaiton of changes to
various lists based on rules (perhaps just simple regex or something)
specified in myDataFile
}
myDataFile {
Cocoon*, *Cocoon, *cocoon, *cocoon*, *Cocoon*,
cocoon-dev@xml.apache.org, message from your loving ApacheWikidaily
diffs;
POI*, POI*, *poi, *poi*, *POI*, Poi*,*Poi,*Poi*,
cocoon-dev@xml.apache.org, come and get it, fresh POI served from the
ApacheWiki;
}
In short, while a single-page RSS is too specific, a wiki-wide diff
mail list is way to general.
I think the RSS is useful. check it out:
http://superlinksoftware.com/cgi-bin/jugwikitest.pl?action=rss
My personal suggestion would be to find a way to partition the wiki
pages per project and send those diffs to the various project mail lists.
But I have no idea on how difficult/feasible that is with the current
software.
Its highly feasible, I just don't know how wise the facilities
provided are (letting someone say sure mail this out to here seems
dangerous...)
The above suggestion is probably more secure, easy to implement, etc.
Re: Wiki RSS
perl-bashing requestedaction=ignore,agree I'm a crappy perl coder -- and I prefer not to code in PERL... (though I do it every day you'll be hard pressed to get me to do any serious perl coding as a volunteer ;-) ) /perl-bashing I highly suggest you look on the UseModWiki (see ApacheWiki follow the links). I think you'll find a number of patches available.. They seem to be incapable of using diff which means its go here and edit this then do that above this kind of crap However, i'll bet you can find a number of things... That being said.. I'd rather leave authentication off unless we have to turn it on... Which incorporates a limitation as to what we can do stock. (We might need 2 modes...but I think I prefer secure batch scripts and stuff running in CVS) I don't see myself in participating in coding enhancements on the wiki as tis not my itch to do so, but I will be very happy to apply patches (in diff -u format) and the such I could use a hand with this XML::RSS mod local installing stuff... (willing to spring for a phone call inside the continental US/Canada) Got some good advice from a PERL hackerbut I might need someone to spoon feed me... -Andy How good a PERL coder are you? [Actually, Danny Angus had mentioned that he might look at this, but this time of year is busy for everyone] There is a page record. It seemed to me that it ought to be feasible to add a field to each page record with a mailing list address, and then mail change notifications from the edit, when the edit is not minor. This would be additional to what appears to be an admin request/requirement for changes to be posted to an mailing list for logging purposes. But my PERL is infrequently exercised, and I haven't had time to look at the details of implementing the change. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki RSS
If you change the script to compute the database path from url that invoked it. Then setting up multiple wiki's becomes trivial to automate. Inter-wiki linking was trivial for me to setup at my house. Though I see it didn't work out well for Andrew. No.. I just didn't try. Patches welcome. Per project wiki would also enable some other experimenting. Something along the lines of http://httpd.wiki.apache.org / probably allows a range of sufficiently diverse and confusing futures. I've no drive to contribute to that effort, but thats fine if you do. -Andy - ben The site of the true bottomless financial pit is the toy store. ps. Why is there no Starbucks at the ER? Why is there no shipping service at airport security? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [FYI] Cocoon Wiki
Does JSPWiki v2 provide all of the features necessary to host the ASF Wiki? Yeah, well, I think so. I already provides RSS feeds, much better structured content support, I find it more usable and it's java so for me it's a plus (but I understand that for others might be a minus so I won't emphasize that here) Do note that I don't mind other forms of wiki. I picked this one arbitrarily. I picked it because Andy Hunt runs it on his site (http://www.pragmaticprogrammer.com/cgi-local/pragprog?HomePage) It ran nice and stable like, didn't require any maintenance, no databases, etc... Just set the data dir, config any options and you're done. The point of a wiki is simplicity. My only caution... lot of folks have a tendency to extend the capabilities and flexibilities such that it no longer is useful anymore. Those wikis die. The most successful wikis are bascially kept simple. The only enhancement I see myself making is tables because I don't think those are so hard and boy they are sure useful... Granted they can be overused so I understand the arguments against... (see this page for a good argument for tables: http://www.superlinksoftware.com/cgi-bin/jugwiki.pl?HowToUseJavaCollections - don't that look pretty ;-) ) If folks feel like they want to install and volunteer to maintain another wiki, and they're sure its secure, can be feasibly set up with meager resource requirements (no idea what nagoya is but Steven has a pretty fat server behind cocoondev and its running Linux and not FreeBSD which is a BIG plus for Java), then I'm not intending to get in the way You just need to be sure you know the answers: * Will it scale if the wiki becomes widely used and syndicated (UseMod: yes) * Will it require more maintenance than is feesible in a volunteer run organization (UseMod: no) * Is it secure from a exploit my system and bring apache to its knees standpoint (UseMod: yes) * Does it keep it simple stupid (meaning complex markup and flexibility is nice but can be counter-productive, wiki's excel on simplicity) -- (UseMod: yes, very) * Can it be feasibly set up given the amount of Cat Herding that is necessary to come to a decision and acquire rights, karma and resources -- (UseMod: obviously) sarcasm And if you're going to have the usual heated discussion (No I want a PyWiki and bla bla bla) before reaching a decision /sarcasm * Can you migrate the data over feasibly -- (UseMod: obviously) veryserious Those are higher priority than Cool Feature X /veryserious -Andy
Re: Wiki Wiki (has been set up)
Danny Angus wrote: Cool supply a patch and I shall apply it with due haste. In Apachewiki terms that'll be by yesterday then, have-a-cigar for this effort Andy. :-) Thanks. Looks like it was 5 minutes well spent. Thanks to Pier too (whom configured httpd). I think Pier gets my award (http://www.freeroller.net/page/acoliver/20021211#unsung_hero_of_the_revolution) next month. For all the b*tch slaps he gets, he rarely gets accords. I'm very pleased at the rate the wiki is progressing. I've never seen so much content generated so fast. While its mostly stubs right now, at the current momentum by next week we'll have nearly as much doco on the wiki than the main site! Good job everyone! http://nagoya.apache.org/wiki/apachewiki.cgi?RecentChanges Thanks, Andy d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Wiki (has been set up)
I've downloaded the source code, and will have a look see next week. There appears to be some sort of database format, so perhaps I can add a field to the page record as a quick hack. I'm not much of a Perl coder, so if anyone IS a serious Perl coder, I'll bet that they could hack it in posthaste. Sure. And I'll apply it. I avoid coding in PERL when I can. It puts me in a bad mood and I have to wipe the camel poo off of my shoe. However, sometimes its the right tool for the job. (one uses manure to fertilize the garden...so even crap has its place right?) -Andy --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HotJava proposal on the Wiki
Hehe.. . since we don't have a contact: nope, not yet. I suppose only the Sunners that read JavaLobby know ;-) (http://www.javalobby.org/thread.jsp?forum=61thread=6197) Noel J. Bergman wrote: Andrew, With respect to the proposal that Sun be approached to turn over HotJava to the ASF, do you have a suitable person at Sun to fulfill your ContactAtSun - We'll need a contact at Sun in order to make this happen role? Is Sun aware of the interest? --- Noel -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] Sent: Saturday, December 21, 2002 17:19 To: community@apache.org Subject: HotJava proposal on the Wiki http://nagoya.apache.org/wiki/apachewiki.cgi?HotJavaProposal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HotJava proposal on the Wiki
Chuck Murcko wrote: Well, we have contacts at Sun through JCP and other channels. If there are no objections, I'll explore this with them. Unless, of course, someone already has. Sun wanting to do this would seem to be required before anything else can really happen. 8^) Yes. Thank you. Chuck On Saturday, December 21, 2002, at 06:55 PM, Andrew C. Oliver wrote: Hehe.. . since we don't have a contact: nope, not yet. I suppose only the Sunners that read JavaLobby know ;-) (http://www.javalobby.org/thread.jsp?forum=61thread=6197) Noel J. Bergman wrote: Andrew, With respect to the proposal that Sun be approached to turn over HotJava to the ASF, do you have a suitable person at Sun to fulfill your ContactAtSun - We'll need a contact at Sun in order to make this happen role? Is Sun aware of the interest? -Original Message- From: Andrew C. Oliver Subject: HotJava proposal on the Wiki http://nagoya.apache.org/wiki/apachewiki.cgi?HotJavaProposal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HotJava and EOL
I have two thoughts on this. I didn't care for HotJava back when it was alive. It seems to be an injustice to revive it after it finally expired. But, more importantly, it seems to be that to artificially recussitate a project is ... well ... artificial. If a community sprang up around HotJava (or anything else) spontaneously, I would be 100% in favor of us adopting it and giving it a home. But trying to do this artificially seems to ask for failure. You can't fake this. It's got to come from folks that are actually interested. I'm unclear on one point - are you genuinely interested? Perhaps I should actually read the site that you linked to ... So since the code is not open yet. The method I chose was to: 1. Approach the grand community 2. See if there was interest 3. Ask sun for the code 4. proceed with community development from there. Precisely what is it about that you see as artificial? Would Tomcat also qualify for that definition? -Andy
Re: HotJava and EOL
Okay so thats 3 interested committers so far. Any other takers? -Andy Noel J. Bergman wrote: Andrew, Around HotJava, the browser application? I suspect relatively little. Around the component? I know several projects that would love to see it resurrected. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wiki Wiki (has been set up)
If you to wiki go here: http://nagoya.apache.org/wiki/ If you do not don't go here: http://nagoya.apache.org/wiki If you do not yet know the joy of a wiki go here: http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheWiki If your chief issue with the wiki is that it is in PERL go here: http://nagoya.apache.org/wiki/apachewiki.cgi?AndrewCOliver And regardless.. Have a nice period of time starting from now, -Andy
[Fwd: HotJava]
Thats one more person interested in a HotJava project. ---BeginMessage--- Hello, I don't participate in Apache projects, but I'm interested if HotJava can be taken over (interested in working on of course, and give time). Damien Bonvillain ---End Message---
Re: Wiki Wiki (has been set up)
Noel J. Bergman wrote: Andrew, Hallalujah! I have been asking about a Wiki on and off for months, and was told as recently as a week ago that there were security reasons for not yet having one. Kudos for just getting this done! I have security tested this wiki and its been running in multiple installations on my server. Besides this, it isn't any more dangerous or priviledged than bugzilla. (and less so probably because bugzilla is names such not because of its function but because it is a giant bug with bug reporting features)... I am not familar with the code of this particular Wiki engine. What would it take to attach an optional mailing list attribute to a page so that when the page is edited, a notice can be driven to the mailing list? Or so that a daily/weekly report could be generated containing that info? I do not know. http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheWiki lists everything I know. However there is this: $UseEmailNotify = 0; # 1 = allow email notification, 0 = don't $NotifyDefault = 0; # Default for email notify checkbox on Edit page. $EmailFrom = Wiki; # Text for From: field of email notes. # (But Reply-to; is set to same as To: anyway.) $SendMail = /usr/sbin/sendmail; # Full path to sendmail executable configuration information in config. If you wish to research it and supply a patch please look here: http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheWiki and follow the instructions. The primary communication mechanism is the push-model mailing list. A Wiki is basically pull-model. I'd like to see push-model notification integrated into the Wiki, which is something I am considering adding to vqWiki when I've some time. Cool supply a patch and I shall apply it with due haste. Thanks, -Andy --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF Member/Committer AUP
Noel J. Bergman wrote: I've been working on this for those windows users: http://jakarta.apache.org/site/idedevelopers.html Thanks for the feedback! Looks good so far. The sections on Ant and CVS apply to non-Windows users, as well. And you might want to include Maven/Jelly in the section on bulding, which currently has only Ant. I've invited Mavenites to contribute, I've not recieved anything. Since I do not use Maven, I feel unqualified to write that section. I'll probably add one on Centipede and wait for the enthusiastic response that I'm sure will follow when I mention it and not the other. Since most projects still use Ant, I covered it first. In my opinion everyone needs to learn ant before they move on to the ant-based-tools. (Those help you later)... Other topics for your list: What is GUMP (just an example, I know what it is)? Yes links to GUMP (http://jakarta.apache.org/gump) is a good idea. Though I hear its not very good (J/K) ;-) The use of logged IRC channels for ASF projects (that appears to be done on some projects -- is it generally available?). What are each of the internal mailing lists, and what topics are they intended to host? I've heard of some that don't appear to be linked from any page that I've noticed (probably one for thie discussion, for example :-)). No they are linked quite clearly from the page that says mailing lists (http://jakarta.apache.org/site/mail.html). however one must read the guidelines to get to the click here (or just have a keen eye ;-) )... Noting the location in the text is probably a good thing to do. I'll do that. In general, I'd want a document that explained the existing policies, mechanisms, and best practices, including where to go for more detail. That is for another page.. . Its pretty clear here: http://jakarta.apache.org/site/guidelines.html My goal is to explain what things are and how to use them Jon others have explained policy pretty well in my opinion. However, I've been informed that all of my opinions are ill informed... Including that one. ;-) -Andy --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Daniel Rall wrote: Jeff Turner [EMAIL PROTECTED] writes: ... Alternatively.. Let's abandon all this wishy-washy 'community' guff and focus on what matters: the code. As Coding Machines, I say each new committer be assigned a serial number by which they are addressed publicly. With luck, we can eliminate any trace of this 'individuality' that dilutes the Apache brandname. --CM029476 ROFLMAO I'd like to be #6 [1] -jAndy.NET [1] http://www.the-prisoner-6.freeserve.co.uk/
Re: [proposal] creation of communitity.apache.org
Right, well the home pages are there now. And right now they are more closely associated with Apache itself than community.apache.org would. You're bringing up a new issue as to whether they should be taken away. The matter at hand is the creation of a new alias to in a way make them more associated with individuals and Apache communities than apache.org itself. You have a corporate viewpoint of how Apache's relationship with Sun should be managed. I tend to think letting them know is fine. (Somehow any explanation of this would probably start sounding like the cluetrain manifesto...which I never read because it was too long winded, but whatever).. Let them decide based on the merits on whether they want to continue their association.. Regardless, I think this is a matter of trust and distribution of control. -Andy I'm afraid of it reflecting poorly upon the ASF. Not matter how hard you try to say that the content isn't representative of the ASF as a whole, as long as the content is hosted on our site/domain, it will be deemed as such. Imagine the day when one of our committers rants about Java on their community.apache.org/~name page and it is posted to /. and Sun gets its panties in a knot due to the bad publicity. If a member or committer does this in a non-ASF forum, fine. But, giving people a platform from which to imply association with the ASF isn't helpful to the foundation or its mission. Reacting passively to these situations isn't going to help. Once the story would be posted on /., we're all in hot water. I believe the best course of action is not to encourage this behavior. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF Member/Committer AUP
Personally I prefer late-refactoring. Has it been a problem yet? Glenn Nielsen wrote: I have been following the discussion about publicizing ASF Member/Committer home pages. The contentious issue seems to be what is appropriate use of a home page hosted on apache, or even if there should be home pages at all. A major concern of those against the proposal is that pages hosted at apache.org will be seen as represensting the ASF. They are concerned about protecting the Apache brand. Throughout the discussion no one pointed to any ASF documentation on what acceptable use is. With the ASF developer community growing to over 500 committers perhaps what is needed is an AUP which addresses appropriate use of their email account, home page, and commit privs. Nothing draconian, but something that can set expectations of what is acceptable use and give the ASF Board/PMC a foundation for making decisions when someone crosses the line. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Aaron Bannert wrote: To me it seems we are trying to solve two problems here: 1) A place to put homepages and personal content, including (but not limited to) ASF-related activities and project proposals, as well as individual interests. 2) A catalog of the people representing the ASF community. IMO the only time #1 should be hosted on an apache.org site is if for some reason the person can not find other space to host the content. I am perfectly fine with #2, as we have already been doing so with contributor pages for the various projects (I happen to think this is more effective than a simple list of all 600 or so committers.) #1 is already there. [more comments below] On Monday, December 2, 2002, at 06:47 AM, Sam Ruby wrote: Aaron Bannert wrote: That is a noble goal, and I support this goal, although I do not think that an organized soapbox is the right way to do this. The short little here's the link to my homepage, oh and I work on this and that project pages are great. Anything other than that is off limits in my book. First, I don't recall Stefano proposing an organized soapbox. Aaron, can you take a moment and take a peek at http://www.apache.org/~fielding/ and indicate specifically what you think should be on and off limits? This is an excellent example of what can go right if we host people's personal homepages on apache.org. Do you believe that every other page we host will turn out the same way? Overall, I would like to see this discussion move away from http://www.intrepidsoftware.com/fallacy/straw.htm arguments (which, to be fair was in response to an argument which at best contained http://www.intrepidsoftware.com/fallacy/pl.htm, and quite possibly could be categorized as http://www.intrepidsoftware.com/fallacy/attack.htm ). What I would like to see this discussion move towards is concrete and specific proposals and objections. And towards building consensus. For starters, we have http://incubator.apache.org/whoweare.html . Now let's entertain the notion of augmenting this allowing each committer to specify (via a completely opt-in basis) with a single hypertext link to the page of their choice. As has been pointed out, this is not materially different that what has been in place on http://www.apache.org/foundation/members.html for quite some time. I have no problem with this, as long as the individual pages are hosted elsewhere than the apache.org namespace. Note that I didn't say hosted elsewhere than on the ASF infrastructure. As long as the people who own the hardware and pay the bandwidth bills don't mind*, I would have no problem with a vhost entry for, say www.friendsofapache.com or www.peopleofapache.com or even www.amiapacheornot.com (tongue-in-cheek :), as long as it doesn't imply that it is officially ASF. *I considered offering hosting space for ASF people who have no other place to put their stuff, but I don't think I have sufficient bandwidth or reliable-enough hardware... Although, I believe per-project listings of contributors with offsite links is more effective, I won't move to block a flat list of every ASF-community member. If acceptable, then lets explore what guidelines we need to place (if any) on the content of pages and how such guidelines are to be enforced. Should the guidelines be different for on-site and off-site content? As Justin pointed out, we get automatic oversight right now when someone makes a change to a project website, including the contributor listings. This works very well for code commits, so whatever we come up with should probably have the same level of oversight. I personally would advocate very minimal guidelines, if any, but would be willing to compromise if that would increase consensus. Is there anyone out there willing to contribute specific proposals along these lines? -aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF Member/Committer AUP
I took a guess regarding .forward and public_html (but I wonder if Windows users would know about them), and played with CVS and ssh to get it all working with public keys. Sent e-mail to Brian detailing my experience, which appears to have been incorporated into the Committers FAQ by someone with a more clever hand at perl than I. Alternatively I've been working on this for those windows users: http://jakarta.apache.org/site/idedevelopers.html Its java specific at the moment, but it doesn't *have* to be. The goal is to educate the new breed whom were weened on Windows Explorer, how to get things done.
Re: [proposal] creation of communitity.apache.org
Ben Hyde wrote: On Sunday, December 1, 2002, at 04:28 PM, Andrew C. Oliver wrote: Wow.. I really do feel like I'm at the Congress of Vienna. huh? (and yes I know what the congress of vienna was). conservatives sat on the left and the more liberal sat on the left (hence where the terms right and left became associated with conservative versus liberal). The two sides to every issue as of late keep bringing this to mind and the very issue pointed to below. It keeps coming back down to this: open (we sit on the left) closed (you sit on the right) and it really keeps being that simple. Exactly how does this have anything what so ever to do with open vs. closed? Whether one wants the community closely associated with the people in it, and make those people more accessible to the world at large. It has everything to do with open versus closed. It has everything to do with whether this looks like a closed geek society (the star chamber) or an open community. And the you shouldn't because I'm too busy too and your visibility detracts from mine is a very different viewpoint on how a community should operate (never been a fan of zero sum ecnomics anyhow) -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Stefano Mazzocchi wrote: Victor J. Orlikowski wrote: Apache is about two things, as I see it: primarily, software and, as a consequence of that software, people. I see it exactly the other way around. Great communities always create great software. The opposite is not always true (see sourceforge). +1
Re: [proposal] creation of communitity.apache.org
Rodent of Unusual Size wrote: it looks like several issues are getting conflated again. 1. should people be permitted to have/publish *.apache.org/~name pages? 2. should they follow any sort of guidelines? 3. should there be a list of them? 4. should a list be mandatory or opt-in only? 5. is it an all-or-nothing proposition (everyone has them or no-one does)? here's my personal take on these questions: 1. should people be permitted to have/publish *.apache.org/~name pages? +1 You must change the term here. Because they already have this. So its should we take it away... to that I vote -1. 2. should they follow any sort of guidelines? -0 (+1 if it's no more than 'don't put anything here that might reflect poorly on the asf') -1 (-1 in that case because it adds the who decides) 3. should there be a list of them? +1. data-driven, either through something in peoples' cvs.apache.org/~name/ directory, like the one-off '.nopublish' i mentioned earlier, or a ~/.homepage like sam (?) suggested, or whatever. +1 agreed. 4. should a list be mandatory or opt-in only? opt-in, of course. well actually technically .nopublish is opt out, but +1 either way. 5. is it an all-or-nothing proposition (everyone has them or no-one does)? -1. someone tries to force its opinion on me about how i may choose to express myself and describe my participation in the asf, i tell it to sod off in no uncertain terms. if someone doesn't like it, then it should a) not do it, and b) not look at others. but don't obstruct people who think the idea has value, particularly since it won't affect *you* in any way. (generic 'you' there, not anyone in mind at all.) -1 agreed! No truer thing has been said in recent times! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for Revolutionaries
They wouldn't have. They would have migrated to SourceForge. That's the problem with an all volunteer army. The can't be trusted to do as they are told. so don't tell them. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
suggestion for news...
Not meaning to embarrass anyone, but I suggest not writing news on any news pages like this: http://jakarta.apache.org/site/news.html#1106.1 The Commons CLI team is proud to announce Commons CLI 1.0, the first official release of this Commons component. Binary and source distributions are available here http://jakarta.apache.org/builds/jakarta-commons/release/commons-cli/v1.0/. More information about Commons CLI can be found on the project home page http://jakarta.apache.org/commons/cli/. The reason being is that its mirrored and carried throughout. Reading thiswhat is the Commons CLI? Why do I care it has a new release...what is in the new release (okay its 1.0 so maybe thats okay).. CLI makes me think of Common Language Interface. Sure there are links but it might be just what someone who gets it in syndication needs, but they won't know based on this blurb and they'll rpobably miss it. Just a suggestion talk amongst yourselves...
Re: @apache web pages
Here is your missing link. Apache isn't about code bases or branding, its about software communities.. These are communities of humans. Such pages help these humans understand each other and build a stronger software development community. And it puts a face on apache. Hope that helps... there is an insider/outsider boundry as it is. Making it unspoken is worse. -Andy Ben Hyde wrote: It would be fun to have an Apache community aggregate of web logs, but I have trouble seeing how it serves the foundation's mission. Sorry to be a wet blanket... I'm concerned that if we create people.apache.org we create another inside/outsider boundary. I've got a handful of other concerns about this, but that's my primary one. Some other ones... I'd rather not co-mingles the Apache brand with the personal web face of individuals in various subparts of the community. Our mission. Creating great software. Puzzling out how to do that productively in cooperative volunteer teams. Releasing that widely under a license that is both open. Crafting an effective open license. One that doesn't entrap folks. I have to do a lot of A supports B supports C supports D before I get to the conclusion that D, building out a mess of committer web pages, supports A, the mission of the foundation. I'm concerned that a few highly vocal members might generate the impression that the foundation is taking positions that it's not. Consider Sam's web log with where he's been poking at RSS - that's not a ASF position. Consider my web log with it's rants on the wealth distribution - that's not an ASF position. The easiest way to avoid a star stage is not to build the stage. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The Apache Jakarta Law (Scientific?)
The Apache Jakarta Law: Any discussion regarding Apache Jakarta will eventually degrade into a discussion about the Tomcat 3.3/4.0 issue, often including a full re-analysis of the events, revision of the history, and sometimes degrading into a full re-enactment of the emotionally charged flamewar that engulfed the Tomcat project at the time. Often even those who don't often participate in such interesting uses of time will even match the judgement logic necessary to participate in such a conversation. I hope one day my Law is proven false. Perhaps if those involved were to take this on to a wiki and document all about it, the different view points and lessons learned, opposing lessons learned etc, we could one day make this law obsolete at least. -Andy Joe Schaefer wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: [...] I believe it was a mistake to allow two different codebases to share the same name. I'm not convinced that having two codebases is necessarily a mistake. So far the discussion here seems to have centered around the concerns of the existing tomcat developers. I'd like to know what the tomcat users (ie. the future tomcat developers) think of the 3.x/4.x division.
Re: The Apache Jakarta Law (Scientific?)
Alright, here you go. Get it out of your systems flamebait degree=total so I hear 3.3 was a total waste of time and that 4.0 was the best thing ever and that 4.0 is way faster than 3.3. /flamebait flamebait degree=total mode=silly So I hear 4.0 was a big evil conspiricy on the part of Sun via Craig McClanahan who is really a drone for the borg and Scott M is actually the Hive Queen with a holigraphic field around him to make her look human. I hear 3.3 was the rightous product of REAL apache people. /flamebait Though I could be wrong... -Andy :-D Costin Manolache wrote: So far it seems Stefano ( who is not currently a very active tomcat developer) is pissed off by the decisions made on tomcat-dev. I don't see too many tomcat developers flaming each other. IMHO most ( or all ) tomcat developers agree that both code bases had some good and some bad parts. I also think most of the tomcat community is behind 5.0, which is a merge of ideas and code from both 3.3 and 4.x. And I think users were very well served, and the outcome is one of the best possible. In the end we have a far better community and a lot more tolerance and understanding. Costin On Tue, 2002-11-12 at 08:28, Andrew C. Oliver wrote: The Apache Jakarta Law: Any discussion regarding Apache Jakarta will eventually degrade into a discussion about the Tomcat 3.3/4.0 issue, often including a full re-analysis of the events, revision of the history, and sometimes degrading into a full re-enactment of the emotionally charged flamewar that engulfed the Tomcat project at the time. Often even those who don't often participate in such interesting uses of time will even match the judgement logic necessary to participate in such a conversation. I hope one day my Law is proven false. Perhaps if those involved were to take this on to a wiki and document all about it, the different view points and lessons learned, opposing lessons learned etc, we could one day make this law obsolete at least. -Andy Joe Schaefer wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: [...] I believe it was a mistake to allow two different codebases to share the same name. I'm not convinced that having two codebases is necessarily a mistake. So far the discussion here seems to have centered around the concerns of the existing tomcat developers. I'd like to know what the tomcat users (ie. the future tomcat developers) think of the 3.x/4.x division. - 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]
DOH! Re: Rules for Revolutionaries
Well this makes my second mail faux pax this week. I actually didn't mean to send this. I sometimes type a mail and then discard it or send it to my self.. U/F in mozilla mail (which I'm not accustomed to) send is right below the file menu and I missed. (new laptop). My sincere appologies to Craig and the rest of y'all. I meant to send a way less snide/sarcastic version of this... Andrew C. Oliver wrote: A slightly more formal way to do this would be to explicitly canonicalize Apache Way policies like this at the apache.org level, and these automatically become the default policies for any Apache project unless that project deliberately (perhaps within some limits TBD) chooses to operate differently. The requirement for following these (or specializing them) would be an explicit part of a new project's charter. yes. Canons are way more efficient than trust and community building. I mean a tight nit group of people whom respect each other and want to work together is NO match for a group of people who don't respect each other and barely want to work together with a set of canon laws. (or should their be three n's in that) Essentially, this would be a generlization of the way Jakarta projects deal with coding style conventions -- there's a default (from the original Sun coding standards) that is the assumed standard unless a different choice is explicitly made and documented for a particular subproject. Yes, bracket placement is the most important issue in a community. If you don't use KR style bracketing I just can't read your code and the project is a total wash. ;-) Fortunately Eclipse lets me reformat it going in and reformat it going out. The same principle can be applied recursively -- instead of subclasses formally inheriting methods and instance variables (with the option to override), projects and subprojects formally inherit culture and standards unless they explicitly choose to override :-). Yes standards have worked so nicely in the software industry. Why we have several standards for any one thing. Its certainly better than mutual respect.. For as long as one follows one of the standards, it must be good. I'd bet many people perceive that Apache actually works this way; let's just make that perception into reality. In order to do this, lets set at least 6 months aside each to draft a large legal document, assign penalties for breaking any of the rules. We'll create a new subproject for Those who have not joined the shining path to enlightenment for projects choosing not to ratify the canon. Next we can create a interperator subproject, in the event of a disagreement among parties in a project the interperator (think of them as lawyers) can be assigned to help interperate the canon and apply penalities to whomever is judged to be in the wrong. The alternative is to get back the the basics...community, mutual respect, dare I say friendship, working for the best ideas, etc. Rigid guidelines are much easier than that. Thats why XP is such crap, a metaphor instead of a BUFD. Same prinicipal. Long live the SDLC! -Andy Craig - 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: DOH! Re: Rules for Revolutionaries
Actually, I quite enjoyed the reply :-). And the cautions you raise are definitely relevant. Well I meant every word of it I just meant to state it...differently ;-) You can over-engineer anything, including a community. But you can also under-engineer, and I get the impression that's sort of where we are right now. The way you describe it sounds like this parable that was told at my kid's cubscout meeting. Where everyone was having fun and doing cubscout things... then the trust was gone and all these strict rules were given and no one shared or helped each other and etc etc... till one day someone just started doing the old things again and it affected everyone and soon everyone was sharing and doing cubscout things. Coming from a corporate background, trust me. Engineering communities doesn't work. Nor does regulation, and beurocracy. I promise to drive this point to death ;-) Next year if anyone is interested in camping in the middle of the Dorton Arena in Raleigh, you're invited -- its quite a touching speech. Theoretically our tent sleeps 6. -Andy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DOH! Re: Rules for Revolutionaries
Often the uncensored version requires a dictionary and a book called Why we say it at hand to get the undertones and coloquialisms. ;-) http://www.m-w.com http://www.amazon.com/exec/obidos/tg/detail/-/1555210104/qid=1036809530/sr=8-4/ref=sr_8_4/102-8855271-2563317?v=glances=booksn=507846 James Taylor wrote: The scary part is that all of us who have been flamed by Andy now need to wonder what the first version of those messages looked like! Yikes! grin -- jt On Fri, 2002-11-08 at 20:03, Andrew C. Oliver wrote: Well this makes my second mail faux pax this week. I actually didn't mean to send this. I sometimes type a mail and then discard it or send it to my self.. U/F in mozilla mail (which I'm not accustomed to) send is right below the file menu and I missed. (new laptop). My sincere appologies to Craig and the rest of y'all. I meant to send a way less snide/sarcastic version of this... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for Revolutionaries
Leadership is best achieved and recognized through informal means. Stefano often exerts quite a bit of leadership over Cocoon because the committers respect him. Creating formal owners is a great way to fork a community, but it fails as a social experiment. Certain members in a community through merit, skill and tact (I obviously am generally difficient in the latter) will be heard more loudly than others. Creating ownership or annointing code leaders is frowned upon by even some of today's more formal software methodologies. Everything is everyone's responsibility. I think guarding and guiding the door to committership on a project until the person demonstrates cohesion to the group is a more effective method. As evidence that the control idea doesn't work, please look at the state of modern software developent within most Corporations. It sucks. Linus, etc exhert a lot less control than you think. -Andy Ceki Gülcü wrote: I keep wondering why you keep bringing up Duncan's Whoa Bessie... mail. I mean this one: http://marc.theaimsgroup.com/?l=ant-devm=97712718421034w=2 Is it just for historical purposes? Is it because Duncan expresses interesting ideas with eloquence? Sure, Duncan may have been wrong in the Ant context but that should not discredit his ideas altogether. The liberal ideas expressed by Stefano, Sam and to some extent Costin are very inspiring and definitely please a wider audience than Duncan's ideas defending the actions of a selfish pig as he puts hit. (No, I don't think that Duncan is a selfish pig and you shouldn't either.) However, liberal ideologies are just that, ideologies. While Duncan's theory of benevolent dictators might not find favor in the eyes of this public, we should not discard it as being contrary to the Apache way. We should instead recognize it as being a legitimate way of development. It may even be the dominant way of development at Apache under disguise. In addition, it is much easier to stand up and talk about the interest of the community than the interests of individuals less you come off as supporting selfish pigs or being a selfish pig yourself. On a wider scale, it was very hard for the West to fight Communism because the communist ideology sells much better to the unprivileged. Yet 75 years later, the West won, not because of its persuasiveness but because it had much more to show on the store shelves than the communists. Communism is a great idea but it doesn't work. Capitalism is hard to sell but it ends up having better results on the long run. Coming back to Jakarta, I am not suggesting that anyone is at fault. All I am suggesting is that we to stop trashing the work achieved by individuals acting as clear leaders. Leadership is not bad per se. I may be stating the obvious here. So be it. At 11:01 07.11.2002 -0500, Sam Ruby wrote: I differ with that rendition, and believe that it is harmful to the community for it to be propogated. Duncan rejoined Ant and was immediately accepted as a committer. He started work on an internal fork named AntEater. This went on for a short while, until another fork came along named AntFarm. At that point, Duncan said Whoa Bessie and started to put forward a case that he had a unique right to determine what codebase bore the Ant name. This lead up to a PMC meeeting with Brian and Roy in attendance where it was affirmed that the name of a project went with the expressed wishes of a majority of commmitters to that project. This has been the policy that we have followed in Jakarta ever since. References: http://marc.theaimsgroup.com/?l=ant-devm=97712718421034w=2 http://marc.theaimsgroup.com/?t=97712745500023r=1w=2 http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html - Sam Ruby P.S. It is my understanding that what is now Apache HTTPD 2.0 is also the result of a number of forks, one of which ultimately emerged as being the one accepted by the community. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[offline] Re: Subtle barriers to entry
Stefano Mazzocchi wrote: Andrew C. Oliver wrote: since i answer the asf email, this is something that has bugged the crap out of me, and about which i have complained several times to no avail. there is no canonical /mailing-lists.html location to which i can point people for j random project, so i have to tell them to search the project site for the info. that sucks. so fix it. Uh, Andy, that helped a lot. Thanks. :) No problem ;-) Can you estimate the emount of energy it takes to go into every project and tell them to update their site? or, if you want to do it, why do you think they would agree with you? maybe they don't like the URI name, maye they have a community.html page that already lists those things. or maybe, for whatever reason, they don't want development mail lists to be easy to find (I did needed that once in order to slow down community building!) That is another issue entirely. Whether consistancy and usability has a cost-benefit ratio that makes it worth your while. Or whether consistancy can be a goal in a diverse group of people whom are not beholden to your goal. In fact, Forrest is just *one* possible use of Cocoon. Forrest is a Cocoon spin-off, but the great value is its focus: come up with a way to generate a *nice* web site, nice navigation, nice lookfeel, easy content administration. In the future, we might also include a web-driven content management system on top of Forrest (running Cocoon underneath). Although I use Cocoon for this task, to be honest its not very well suited for this in my opinion (and I'm sorry to say this). Its much slower and sucks down way more memory than anakia/etc does to generate static documentation. Now for dynamic stuff, Cocoon is defintely the cats meow but if it weren't for the fact that Nicola Ken has made documentation with XML brainless for me, I'd probably use something else. I'd like to see either Cocoon increase performance by about a factor of 3 and decrease memory consumption by at least a factor of 3 for static documentation generation or see Forrest support other suck transform engines in a pluggable manner so that those can be fast. I spent several months with my former girlfriend (who is a usability engineer) to design the Forrest layouts and the usability of the navigation. A lot of work has ben put into that, while other efforts (maven, stylebook) simply didn't care about navigation and usability, but just about look and ease of regeneration. And it looks really nice. I can't wait to use it. It has made it on my palm pilot based task list (along with voting to put a burr in Bush's boot which I did today ;-) ). Ease of regeneration is usability for developers. Of course, I'm way biased here, so don't start a maven vs. forrest pissing contest, please. I just want to point out that the only way I see to fix our web interface problems is to create better tools and hardcode a number of usability guidelines into them. I disagree. The tools do not make the man, nor do they make decisions. I'm actually rather suprised to hear this from you. One of the reasons I prefer Centipede (for instance) over Maven is that it enables me to do things my way where maven tends to tell me how I must do them. There is an inherent disabillity towards consistancy in this type of development and I think the best way to afford it is through personal leadership. (Look at the architecture of Cocoon, the only thing consistant about it is Avalon and XML technologiesthe rest is often more different than night and day). Another approach to this (rather than try and create tools for folks to do things your way) is to simply pick up the hatchet and create a site for all of the projects that is consistant and etc. One way to do this is to get like minded people like yourself start it and see if others come and fall in line... Perhaps forrest is exactly that However its success depends on a number of folks saying gee thats a good idea and gee thats easy to use (from a developer standpoint) and that sure is pretty... And in the end since this is apache we'll have at least two competing versions ;-)...Perhaps as our community becomes less western centered we'll become less concentrated on dualism and more concentrated on diverse cooperation. So I think I agree with your methods and, etc, but not your perspective on the matter ;-) Starting with a project.xml info file is a great thing and we can keep going from that point on. I agree. -Andy
Re: [offline] Re: Subtle barriers to entry
Dohsorry stefano I meant to send that just to you fat fingers strike again. Andrew C. Oliver wrote: Stefano Mazzocchi wrote: Andrew C. Oliver wrote: since i answer the asf email, this is something that has bugged the crap out of me, and about which i have complained several times to no avail. there is no canonical /mailing-lists.html location to which i can point people for j random project, so i have to tell them to search the project site for the info. that sucks. so fix it. Uh, Andy, that helped a lot. Thanks. :) No problem ;-) Can you estimate the emount of energy it takes to go into every project and tell them to update their site? or, if you want to do it, why do you think they would agree with you? maybe they don't like the URI name, maye they have a community.html page that already lists those things. or maybe, for whatever reason, they don't want development mail lists to be easy to find (I did needed that once in order to slow down community building!) That is another issue entirely. Whether consistancy and usability has a cost-benefit ratio that makes it worth your while. Or whether consistancy can be a goal in a diverse group of people whom are not beholden to your goal. In fact, Forrest is just *one* possible use of Cocoon. Forrest is a Cocoon spin-off, but the great value is its focus: come up with a way to generate a *nice* web site, nice navigation, nice lookfeel, easy content administration. In the future, we might also include a web-driven content management system on top of Forrest (running Cocoon underneath). Although I use Cocoon for this task, to be honest its not very well suited for this in my opinion (and I'm sorry to say this). Its much slower and sucks down way more memory than anakia/etc does to generate static documentation. Now for dynamic stuff, Cocoon is defintely the cats meow but if it weren't for the fact that Nicola Ken has made documentation with XML brainless for me, I'd probably use something else. I'd like to see either Cocoon increase performance by about a factor of 3 and decrease memory consumption by at least a factor of 3 for static documentation generation or see Forrest support other suck transform engines in a pluggable manner so that those can be fast. I spent several months with my former girlfriend (who is a usability engineer) to design the Forrest layouts and the usability of the navigation. A lot of work has ben put into that, while other efforts (maven, stylebook) simply didn't care about navigation and usability, but just about look and ease of regeneration. And it looks really nice. I can't wait to use it. It has made it on my palm pilot based task list (along with voting to put a burr in Bush's boot which I did today ;-) ). Ease of regeneration is usability for developers. Of course, I'm way biased here, so don't start a maven vs. forrest pissing contest, please. I just want to point out that the only way I see to fix our web interface problems is to create better tools and hardcode a number of usability guidelines into them. I disagree. The tools do not make the man, nor do they make decisions. I'm actually rather suprised to hear this from you. One of the reasons I prefer Centipede (for instance) over Maven is that it enables me to do things my way where maven tends to tell me how I must do them. There is an inherent disabillity towards consistancy in this type of development and I think the best way to afford it is through personal leadership. (Look at the architecture of Cocoon, the only thing consistant about it is Avalon and XML technologiesthe rest is often more different than night and day). Another approach to this (rather than try and create tools for folks to do things your way) is to simply pick up the hatchet and create a site for all of the projects that is consistant and etc. One way to do this is to get like minded people like yourself start it and see if others come and fall in line... Perhaps forrest is exactly that However its success depends on a number of folks saying gee thats a good idea and gee thats easy to use (from a developer standpoint) and that sure is pretty... And in the end since this is apache we'll have at least two competing versions ;-)...Perhaps as our community becomes less western centered we'll become less concentrated on dualism and more concentrated on diverse cooperation. So I think I agree with your methods and, etc, but not your perspective on the matter ;-) Starting with a project.xml info file is a great thing and we can keep going from that point on. I agree. -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Jakarta PMC bylaws change
It smells like a pretty good idea to me. One question thoughdo you ever sleep? (3:52AM)? Sam Ruby wrote: I'm planning on submitting a proposal to change the bylaws of Jakarta to bring Jakarta's PMC structure closer to the HTTPD one. Before I do so, I would like to gather the opinions of a self selecting cross section of both Jakarta and non-Jakarta committers, and it occurs to me that this mailing list enables me to do exactly that. My intent is not to rush to put in place any radical change, or to address all issues in one sweeping proposal. My intent is merely to put in place enough bylaws to enable the necessary changes to be made. My current thinking is to propose this formally after the ApacheCon to give people adequate time to discuss this, but feedback on both the content and timing are welcome. Enough preamble. Here's the outline of the proposed changes: 1) Eliminate any upper limit to the number of PMC members 2) Allow new PMC members to be proposed at any time 3) Remove references to resigning, add an emeritus status 4) Reinstate all past PMC members as emeritus status In addition to these bylaws, I anticipate a set of non-normative guidelines. Proposed PMC members will normally already be committers. Typically, a proposed PMC member will have been actively involved on a sustained basis (no significant gaps) for six months since becoming a committer. I intend to nominate any ASF members who are also Jakarta committers as new PMC members. The intent is that this is intended to be orthogonal to any proposals to promote an existing Jakarta subproject to become a top level project. Of course, people involved may voluntarily chose to change their status to emeritus, but are under no obligation to do so. Thoughts? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subtle barriers to entry
Is this just driven by the number of config questions and suscribe (and other) trolls to the dev lists? Or the rising percentage of doofuses in the net world? I knew we should never have let AOL hook up that gateway to the net. 8^) yes. yes. agreed.
Re: Subtle barriers to entry
since i answer the asf email, this is something that has bugged the crap out of me, and about which i have complained several times to no avail. there is no canonical project/mailing-lists.html location to which i can point people for j random project, so i have to tell them to search the project site for the info. that sucks. so fix it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subtle barriers to entry
So just use gmane.org or pier's new nifty news.betaversion.org onces its off his DSL (somehow I don't think he wants everyone using it just yet ;-) ...but Pier is weird so maybe he does ;-) ) Henri Yandell wrote: On Mon, 4 Nov 2002, Rodent of Unusual Size wrote: Chuck Murcko wrote: I've noticed in looking around the Apache sites that there's a lot of inconsistency in providing links (usually in the sidebars) where people can get on the mailing lists. since i answer the asf email, this is something that has bugged the crap out of me, and about which i have complained several times to no avail. there is no canonical project/mailing-lists.html location to which i can point people for j random project, so i have to tell them to search the project site for the info. that sucks. The mail archives also seem to be a joke. They lack a common look and feel, sometimes they don't cover certain mail lists and other times they just feel like poor quality user interfaces. From my point of view, the mail server [ezmlm I think] seems to be a lot more cryptic than the mail server I administer [mailman] so I keep wanting to find the web-interface to my mail list, and then discovering I have to use this cryptic set of commands to the mail server, which I routinely forget :) I'm sure it'll turn out that ezmlm is more powerful etc, and I'm not wanting to start a religious war, just my AOLuserness. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: comments on the votes
I would not expect for most votes to get more than a 25-50% turnout provided the vote is going the direction the person would like. Ken gave a subscription figure that was much higher, so I suspect that this was the result of the silent majority feeling sufficiently represented. Sanjiva Weerawarana wrote: Hi Stefano, It looks like there were only 69 votes cast. How many committers do we have in all? My intuition had been that it was 69, but I could be wrong. I wonder whether this list has brought over a sufficient mass of the community to be representative of the community. One could of course argue that for this particular list we only care about the opinion of the members of this list .. Sanjiva. - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: community@apache.org Sent: Saturday, November 02, 2002 4:31 PM Subject: comments on the votes The previous message was a dry summary of the votation, but here I would like to comment it. First of all, I was very happy to see that 'openness' doesn't appear to be a quality of any particular group of people. I perceive this somewhat reducing the value of Sam's thesis that jakarta has an 'open' attitude that the rest of the ASF doesn't have. I saw individuals voting on their own personal feelings and the results where that voting results are very diverse. I consider this a healthy sign that communication is really taking place and this list might well make a difference in the creation of the *perception* of a ASF-wide community. Moreover, the majority expressed no reasons to restrict the 'transparency' of this list (thru public archives), but was concerned on the ability for everybody to subscribe, but my perception is that it was not due to some 'unopen' practices, but only to the worry that S/N ratio would lower as it happens, for example, on [EMAIL PROTECTED] The result of this votation turns this list into a sort of 'house of representatives' where only elected people are able to talk, but everyone is able to read the digests. Ah, one personal comment, we really need a better voting system :) doing it by hand is boring and very time consuming :/ Roy, how do we use your voting system? can it be extended to committers? -- Stefano Mazzocchi [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: comments on the votes
Stefano Mazzocchi wrote: Ah, one personal comment, we really need a better voting system :) doing it by hand is boring and very time consuming :/ +1
Re: [VOTE] Openness
Hmmm. I looked at the datestamp of the original vote message and it looked like I was under the 78 hour window for voting. But you are correct, it doesn't matter since I am just affirming the result. I thought it was 72 hrs ? ;-) Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF Membership Nomination
I'm looking for the text version of this: http://jakarta.apache.org/site/agreement.html which is supposedly in text form SOMEWHERE in CVS in some module... Oh, that cottonpicker. Sent via separate mail. For some reason it's in foundation, and I don't know why it was never released out of there once final. where in CVS is it? Just for future reference? All of the above. On the one hand, because thats the way we've always done it doesn't invalidate a process that works. It might need to get that written down for some to feel better with it. On the other hand free speech is cool with me, it should go without saying. 8^) It is customary to abandon working within a system if one exhausts all avenues there, and work outside it. I don't think that's been done here yet. I do realize some folks think they have exhausted all alternatives. That disconnect alone is fertile soil for polarization. No I think its openness vs closedness.. Saying exhaust all avenues working in the closed system to see if that achieves the openness you desire is kinda self-contradicting? I didn't cast this as closed vs. open, nor as closed=bad and open=good, because I think both have proper places in running the show here. Is this difference more accurately described as If I can't see it I worry that there's bad juju going on vs. If I can see it I can see all the good and bad juju going on? That seems to be basically a trust issue to me. So maybe we hit the root of all the weirdness at last. Could it be that we don't trust each other to be working in each others' best interests? I would hope they are common interests or we are SOL. Implementations we can vote on all day, but trust and common direction are either there or they are not. But for instance Sam is a member and he's a Jakarta/XMLer. Besides I think the trust issue goes both ways... Before this list, I had no idea who most of these people I was trusting were! Only by rumor/reputation and google. So who did I trust? Sam and Stefano. This list is part of the change.. and its already making a difference. -Andy Which I guess is basically the part I agreed with... Rather than having a philisophical discussion on it...lets you and I lead by example.. . ;-) +1. Gotta get back to work now. But I'll be back. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Proposal] Compromise was: Re: ASF Membership Nomination
Tradeoffs with the old and new method: 1. doing it privately tends to perpetuate the closed mysterious nature of it (good ol boys club). Another way of looking at this would be in relationship to the Cocoon project. The less documented aspects of it are less used outside of the cocoon developer community and the undocumented nature of much of it prevents its widespead adoption in a number of locations. However this has begun to change, the project information is starting to become shared through the efforts of people like Steven Noles. Secondly, a number of books have started to be written on the subject. This has improved the project substantially IMHO and recent designs are starting to be better thought out and are including new ideas not before approached such as XMLForm by this fellow named Ivelin. 2. doing it publically could result in hurt feelings and divisiveness and the instances Stefano gave... Possible Compromise 1. Nominations could take place on the Community list. Social contract be to only say nice things on the list and offer feedback to the members@ list if its negative. Negative comments made on the community list are rebuked and noted as unproductive and in bad spirit. Nothing nice said is probably a good indication of lack of support or everyone is busy ;-) 2. Voting and any negative discussion happens on the members@ list Tradeoffs: 1. Still somewhat closed but still more open. 2. The person proposed is hinted to be on their best behavior so they can't act like me ;-) 3. The person can just wonder who doesn't love them ;-) I think 3 is moderated by the idea that I figure probably most folks are asked if they'd accept the nomination beforehand anyhow so I doubt they don't know in advance. Any additional thoughts? -Andy Stefano Mazzocchi wrote: James Cox wrote: You make a lot of good points. Let me be devil's advocate and make a couple explicit points that I think you imply above: 1) ASF membership is very important 2) ASF membership is more likely to be contentious than other decisions for that reason Perhaps some middle ground could be reached? A public discussion on merits followed by a private debate? Leave the decision of whether or not to address the candidate directly to each member? Maybe at the end of the day, the community list is the wrong place for the ultimate resolution of the process, but it may be a useful auxiliary tool. +1. Greg, you make -- as always -- some very fine points, however Morgan has really pointed it out here. This is an important issue, but sometimes it's nice to have a general forum to gauge opinion :) Don't know if you guys are familiar with the architectural concept of 'Inversion of Control' (IoC). If not, please read http://jakarta.apache.org/avalon/framework/guide-patterns-ioc.html This is also called 'the hollywood principle': don't call us, we call you. The ASF adopts the pattern of IoC when proposing new members: that means: one gets called only when voted in. Otherwise, life continues with no problems. This allows, for example, resolutions like I think he/she is not ready yet. I would personally be very pissed if somebody told me that I'm not ready *yet*, because if they assume I will be, then why don't they vote me in now? and maybe that impatient attitude is exactly what they want me to learn. I think Sam is mistaken thinking that openess = better and committers nomination = members nomination always. So, I think we should stick with the old IoC nomination model of members proposing a committer on [EMAIL PROTECTED], and, if voted in, presented the membership here on community@ and, if voted out, keeping this silent. But I might well be wrong.
Re: ASF Membership Nomination
how many know they are supposed to? Googling is the solution? humm.
Perhaps the most famous and capable web development organization
should come up with a better method of organizing its web content
than go search on google for what it means to be part of the ASF...
I'm not saying ASF shouldn't write stuff down. Perhaps we need an
asf-docs project, since lots of this is not written down because
people like to code, not doc.
I do think it's inaccurate to say that none of the information exists
elsewhere. And I don't think that saying it's not all written down yet
should be a valid excuse for not learning elsewhere. Would that reason
be valid for any of us not to do our jobs? We all do research to
understand what we need to write code; is it *that* unreasonable to
expect folks to do a little research in the same vein regarding ASF?
If they do not know what questions to ask, how are they to find the
answers? I have read what documentation was apparent to me and I feel I
have a reasonable understanding of how things work.but what if I
don't? How do I know what the base set of information I should know is?
Writing things down and even mandating they must be read is not going
to get people who don't want to read them to do so. I am surprised
that people must be made to know they should read and learn more about
ASF. It seems to me like having to tell people they need to read the
loan terms before buying a car or house. IMO some of this *should* go
without saying.
No but organizing the information into a this is the minimum you should
know will lead many people to read at least that. Then they will
hopefully ask more questions.
Perhaps the bylaws are insuffiently disseminated. Sure its on the
web... Sure its on the apache site...but have you read EVERYTHING on
the apache site? OR do you read what you look for or what strikes
you in the face immediately as being important. A basic rule of
send this link with this set of 'read this at minimum' to all
committers seems more sensible.
As opposed to expecting folks to want to learn about it? Pertaining to
discussions on this list and reorg@, is it reasonable to assume that
anyone *hasn't* read the bylaws?
I've read them, but many people didn't subscribe to it at first, some
people don't speak english natively and so the legalistic language may
not be very digestable.
For instance, I'd like very much to link the text version of the
committer for to the jakarta webized version. I hear its not on the
web but its in CVS... I have absolutely freaking no idea where.. .
Sure its there...but a needle in the haystack.
I am not saying this to be trite, but that's what tools are for. I use
the cshell alias
gff find !:1 -name !:2 -exec grep !:3 {} \; -print
a lot here.
and what do you suggest I search on exactly. Do you feel that this kind
of searching would be okay given the poor performance of the web server
over the last few days?
Honestly it didn't occur to me to shell in and grep through the hundreds
of megs of... I shall do so. (Though not via C shell which I have a
great deal of distaste for :-p)
I disagree. This evolved from a desire for greater openness in the
ASF and a more inclusive framework. Perhaps people such as Sam
already see themselves as viable members capable of evolving the
process and are working out new ideas. Perhaps he feels the ASF
should be more open and is working to improve upon it and is already
familiar with the existing system.
Perhaps. Can you see that there are other interpretations possible?
Especially when it appears we are getting into a situation where we
are chasing our collective tail? Or it appears that we are simply
inventing process as we go here in the face of process that already
exists?
because thats the way we've always done it -- perhaps a more
constructive way to put this would be Can we work to propose the
changes formally before beginning to propose members on the community
list and chaning the process ad hoc, would it not be better for sam to
first put this up to a vote or something before just doing this
On the other hand, perhaps sam regards doing this as free speech leading
up to a formal revision of the process. I guess I'll leave that up to
sam rather than speculate. While I've been posting proposed solutions
to the problems as they are brought up and listing the tradeoffs as I
see them and asking for further input (thereby trying to capture
multiple viewpoints) , I think we're making progress on trying to build
a more cohesive and open community... But then again, I'm a crazy man.
Perhaps that is not the most enlightened statement I've heard.
Perhaps statements like this lead to disenfranchisement and make
those Jakarta committers feel that way. Especially since you're
attacking (I think) the very group whom have come here to try and
bridge the gaps.
I made a statement about possible perception, not an accusation. I
Re: ASF Membership Nomination
That is not what I meant... there is supposidly a txt version. Sam Ruby wrote: Andrew C. Oliver wrote: I'm looking for the text version of this: http://jakarta.apache.org/site/agreement.html which is supposedly in text form SOMEWHERE in CVS in some module... http://cvs.apache.org/viewcvs.cgi/~checkout~/jakarta-site2/xdocs/site/agreement.xml - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tapestry joins Jakarta
Awesome. Thanks Erik. You're like a pillar of the Java side of Apache and I mean that. And you write a nice book too ;-) -Andy Erik Hatcher wrote: Count me in for providing whatever assistance I can spare for helping Tapestry join Jakarta. Just ping me and let me know what if anything I can do to help. Erik Andrew C. Oliver wrote: Mr Ship, I totally disagree with Pier's statement (and you'll find many here will feel the same as I on this). The opinion of Tapestry joining is very good. Realize Apache is more like a confederation than anything. So different people feel differently. We're still ironing out a new process as Pier said, however most folks I've spoken to have felt that the Apache voting rules must be adopted as a first step not later. Dion and I have both committed to helping you with this transition (though I don't think he ever stated so publically...Dion?). And I'll be happy to subscribe to the tapestry list if you desire and help you build the structure. The steps as I see them: 1. Adopt apache voting rules 2. Vote to join and relicense (in one swoop) 3. Submit a formal proposal 4. You're in The challenges ahead are: 1. Apache: figure out what the procedure is that you will join under (my position is it doesn't matter as long as things are relaxed on you because we wanted to try something out and that things aren't full of extra hurdles because the procedure is in transition) 2. Tapestry: Find your voting committers, reorganize yourself into a meritocratic structure 3. All: Patience and due dilligence. Me Dion 1. Find a sponsoring member 2. Assist you in reorganizing 3. Assist you in your propoasal 4. Make our case 5. Assist you in getting your sources/structures here. Thats as clearly as i can lay it out. Hopefully others will chime in constructively and clear up anything I got wrong or is fuzzy ;-) -Andy Pier Fumagalli wrote: On 26/10/02 15:01, Howard M. Lewis Ship [EMAIL PROTECTED] wrote: So, this went out about a week ago, and the guidelines only cover as far as publishing a proposal on the Jakarta General List. What is the next step? So far, I haven't seen any real negative responses, and a lot of positive ones (I think a lot of ex-WebObjects folks are lurking about :-)). I could summarize in more detail if that would be helpful. Obviously, the PMC hasn't really weighed in. Again, what next? Not being a committer to any of the Jakarta projects, and not being a PMC member, I can't say much on this, but from a general feeling that I gather from different parts of the foundation, I would say that _right_now_ the timing is not that great because of the big reorg going around ASF wide. But the decision is left to the Jakarta committers and PMC members... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[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: [VOTE] Open this list
I changed my vote to open it completely. or just +1 on that too. I favor medium access to closed completely for sure as I freaking hate the ezmlm archives (minimum readability)... I believe we agreed to wait 72 hours... Rodent of Unusual Size wrote: i have just done my best to collate the votes as far as i have seen them in this thread; the result is in the committers module (to which everyone here theoretically has write access) under 'vote-community-access.txt'. everyone please verify that i didn't screw up your votes and put your names in the wrong places! here are the results so far: [as of $Date: 2002/10/27 23:22:57 $] Three views exist presently on the appropriate level of openness for the community@apache.org mailing list. The purpose of this list is to fascillitate community development among the various disconnected groups in Apache. Then to further discuss issues that affect the community as a whole. The list was created in direct response to this proposal by Stefano Mazzocchi: 1) a mail list [EMAIL PROTECTED] should be created, it should be open to committers only but it should be voluntary. Here is where ASF-wide discussions should take place and committer and members get to know each-other. Here are the views as originally defined by Andy Oliver in message [EMAIL PROTECTED]: View 1: Open the list completely, anyone can subscribe, post and read the archive. +1: Sam Ruby, Steven Noels, Jeff Turner, Rodney Waldhoff, Craig R McClanahan, Morgan Delagrange, Conor MacNeill, Ignacio J Ortega, Ted Husted +0: Leo Simons -0: Michael A Smith -1: Ken Coar, Sander Striker, Greg Stein, Joe Schaefer, Justin Erenkrantz View 2: Keep the list open only to committers, members and invitees (highly contributive developers and users) so far as posting goes, however allow anyone to read or view the archive (and include an archive such as MARC, etc. +1: Sam Ruby, Andy Oliver, Leo Simons, James Taylor, Aaron Bannert, Conor MacNeill, Erik Abele +0: Craig R McClanahan, Greg Stein, Ignacio J Ortega, Ted Husted -0: Ken Coar, Morgan Delagrange, Joe Schaefer, Justin Erenkrantz -0.9: Sander Striker -1: Michael A Smith View 3: Allow posting by committers, members, and invitees, and restrict access to the archives to the subscribers. +1: Ken Coar, Martin van den Bemt, B.W. Fitzpatrick, Michael A Smith, Sander Striker, Greg Stein, Thom May, Joe Schaefer, Peter Donald, James Cox, Vadim Gritsenko, Justin Erenkrantz +0: Erik Abele -0: Leo Simons, Conor MacNeill -1: Craig R McClanahan, Morgan Delagrange, Ignacio J Ortega, Ted Husted
Re: Man, it's quiet here
go for it. Erik Abele wrote: From a moderators POV I can say, that mostly the people which are subscribed to reorg@ have also joined [EMAIL PROTECTED] Perhaps we should propose another posting on the different developer-/committer-lists? It seems that Greg's and Stefano's postings did not really reach all the committers out there ;-( erik Morgan Delagrange wrote: More than a fifth of the committers already? That's pretty impressive. --- Rodent of Unusual Size [EMAIL PROTECTED] wrote: Andrew C. Oliver wrote: No we settled down util we had more subscribers Ken, are we subscribed up yet? 124 subscribers at present. as opposed to 127 on reorg@, and 579 on committers@ total. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Man, it's quiet here
If true, this should induce a certain conservatism of approach in those who are driving the reorg aganda. There's a silent majority out there who just getting on with the code. Peter So now we're sampling Richard Nixon ;-)
Re: Man, it's quiet here
Or, most people just want to be left alone to write code. :-) Amen :) devils-advocate And remain committers without wanting to becoming members; they just can't stand these time-consuming politics. /devils-advocate why there are no politics in the sourceforge cvs repository ;-) generally no community either... ;-)
Re: [Ant nudge STATUS] Better than we thought...
well principally you should be interested in this communication. Another PRO... more opportunity for ant committers to become recognized and achieve membership. .. um, you say that like there is an end-gain An honor more like. . Plus the opportunity to have more influence in/benefit from the most influential software development organization ever. Certainly this involves responsibility. Few things worth anything don't. If you don't feel that waythen I guess why are you here? is a good question. To write code isn't good enough. You can do that on sourceforge. then again this may be the effect of the real system for committership... (fine...apply your patches yourself if you don't think I do it fast enough ;-)) I'm not on the ant list but I would be definaterly keen to see such a proposal cross posted to community@ yes. or just moved there. That would be cool! Cheers, Steve. Cheers, Steve. -Andy
Re: [VOTE] Open this list
Thats view 3. (the ezmlm archive is of course always available) Martin van den Bemt wrote: +1 on View 2, without the public archive. Everyone having access here should be able to get to some kind private archive though ;) Mvgr, Martin -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] Sent: Saturday, October 26, 2002 15:38 To: community@apache.org Subject: [VOTE] Open this list Three views exist presently on this list's openness. The purpose of this list is to fascillitate community development among the various disconneted groups in Apache. Then to further discuss issues that affect the community as a whole. View 1: Open the list completely, anyone can subscribe, post and read the archive View 2: Keep the list open only to committers, members and invitees (highly contributive developers and users) so far as posting goes, however allow anyone to read or view the archive (and include an archive such as MARC, etc. View 3: Close the list to all except members and committers. View 1: +1 Sam, Steven Noles View 2: +1 Andy View 3: +1 Ken Andy: I'd like to protect the list from random posters. If a user or someone wants to get in, then fine let them in if they have something to contribute, but this will prevent someone posting a random Gee how do I use tomcat or here is what you should do but I have never and will never contribute to apache in any realy sense of the word posts that often degrade the quality of the list. This will also help prevent a personal experience of mine from repeating itself when I first tried to get involved, where I posted a simple question and got flamed without ever knowing the context rhyme or reasons... Please state your view and vote your conscience. -Andy - 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] Open this list
Okay. Sam and others have convinced me. . though I reserve the right to taunt you all when the J.D.s enter and we have too much goofiness (more than I cause that is ;-) ) lets open it up and see what happens. if havoc is wreaked its correctable so I change my vote to +1 for all open. I think thats the forming consensus so lets wrap this up in the next day or so and just do it. Then some karma blessed person should update the site. Morgan Delagrange wrote: --- Steven Noels [EMAIL PROTECTED] wrote: Craig R. McClanahan wrote: And, IMHO, any open source developer community that tries to ignore users of its products is going to become insular and self absorbed. +1 Given the number of committers on an Apache-wide scale, what I post is meant for global consumption already - and I don't see what the world should be kept away from except for security-related issues. /Steven Yup, I am also +1 for opening the list to all, and -1 for an committer-only list with no public archive. -0 for a list with a public archive but limited subscribers, as combing through archives to get news is an unrewarding experience. - Morgan = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
