Re: Internet mapping server and geographic projects at the ASF
Stefano Mazzocchi wrote: You might want to take a look at what we (my group at MIT) did the international semantic web conference: http://simile.mit.edu/conferences/iswc2005/ Sorry, this was meant to be http://simile.mit.edu/conference/iswc2005/ -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Internet mapping server and geographic projects at the ASF
Philip Mark Donaghy wrote: Inspired by the ApacheCon and a discussion during the closing talks on maintaining a virtual map of the world using devices carried by humans, I wish to propose a project at Apache that does that and more. I would like to seek out interested people who would like to work on mapping software at the ASF. The projects that interest me are, 1. A map server that shows the location of people at the Apache conference. This is for people who wish to remain accessible to others. This idea bothers some people. But as with any ASF project security and privacy are very important. 2. I wrote a portlet application for Jetspeed 2 which uses the MapServer project. This could be separated out as a generic portlet map server. 3. I would like to do a community driven social experiment as a way of gathering global data. 4. A generic Java map server project. I would like to build some better tools for authoring and publishing online maps. 5. Torsten Curdt spoke to me about his ideas of blogging by geographic location. Essentially all blogs are tagged with a location based on IP address. 6. I discussed a mapping project with Chris Schaefer. There is some live data being published by the california highway authority about traffic. It is text and html and lacks a mapping server so it is rather difficult to visualize the information. 7. Google is obviously leading the way in mapping technology. I would like to see an apache project that provides similar quality services. I am learning where my web traffic comes from using Google analytics. But they don't provide interactive maps. Please contact me if anyone is interested. Obviously the incubator is where this project will start but building the community is the first step. Happy holidays everyone! You might want to take a look at what we (my group at MIT) did the international semantic web conference: http://simile.mit.edu/conferences/iswc2005/ and note: we already have scripts that transform some of the ASF data into RDF already. As for an 'apache mapping' project, I think you *seriously* underestimate the amount of resources required to run such a service. Landsat 7 data is available as public domain, for a really nice little program that uses you can check out WW2D http://ww2d.csoft.net/index.php?title=Introduction which is a NASA WorldWind java+opengl clone (and amazingly fast! at least on my mac). There are two tile servers available to the public: one is run my Microsoft (part of terraserver, *not* virtualearth), one is run by NASA (as part of the infrastructure that powers WorldWind). Landsat 7 has a resolution of 15m per pixel, while GoogleMaps is using images from QuickBird (operated by DigitalGlobe) which has 0.6m per pixel (but it's clearly not public domain ;-) I would personally very much like apache to host the software that clones the javascript part of google maps in an open source way, but running the tile server is going to require massive amount of technical infrastructure. A much better idea is to partner with NASA and Coral http://coralcdn.org/ -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: At what point do you unsubscribe/deny a misbehaving user?
Jean T. Anderson wrote: Roy T. Fielding wrote: On Dec 16, 2005, at 5:17 PM, Jean T. Anderson wrote: derby-user@db.apache.org has been grappling with someone who delights in belittling other posters on the list. The topic was raised on women@ (see the thread starting with http://mail- archives.apache.org/mod_mbox/www-women/200511.mbox/%3c4371355F. [EMAIL PROTECTED] ), but I think it's more appropriate for this list. For crying out loud, would you please supply links to the exact posts you consider to be in poor taste and the person's name? I just wasted 10 minutes trying to follow the bread crumbs. You have to make it easier on reviewers -- everyone seems to be painfully avoiding a pointer to an actual message. sorry -- I'm not trying to frustrate folks. I considered posting specific links, but withdrew them at the end, even though they are links to public archives. The name at the core is Michael Segel. Below are links to public responses to some of his posts (which are numerous enough that they alone would be frustrating to wade through): http://mail-archives.apache.org/mod_mbox/db-derby-user/200508.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/db-derby-user/200510.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/db-derby-user/200511.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/db-derby-user/200512.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/db-derby-user/200512.mbox/[EMAIL PROTECTED] The first two posts were disassociated from the offending message and the tactic clearly didn't work. The last two were recent (this week). Off line communication makes me believe he has no intention of moderating his behavior, hence the question of at what point you unsubscribe/deny a user. In general, it is the responsibility of the PMC to govern its own lists. If the PMC decides to boot them, then go ahead. Most groups just shun the user. One of the DB PMC members was asking about frequency of denial, which is an excellent question, which Noel responded to with Rarely. Really really rarely. It's helpful for us to know how other projects at the ASF handle such situations. I'm getting questions from users asking why we don't just boot him. I'm happy to respond with The ASF doesn't like to do that except for the most extreme cases if that is the right answer. This case is merely very annoying, not extreme. I think ignoring is an excellent tactic for a developer's list. I worry that isn't strong enough for a user's list, but I also wouldn't want to embark on a path that could backfire. One technique that I have applied with very nice success works like this: 1) somebody crosses the line of respect and you see a pattern [at this point you feel you should say something: *DON'T*] 2) but somebody less clueful will 3) you flame the #2 guy Now, it sounds pretty weird but this is the rationale: 1) those who cross the line of respect with a pattern do it intentionally, the motivations are numerous but they are normally asking for help or they are just looking for a good fight 2) in both cases, replying to him (yes, him, it's *always* a guy) and tell him what the rules of the community and stuff like flame-free zone are just going to make things worse. If he wants help, he'll start looking for the fight, if the fight was what he was looking for, he found it. 3) there is always somebody in the community that doesn't know this pattern, so they will reply quietly or, even better, they will flame him. 4) if they flame him back, it's easier: just flame the counter-flamer. The counter-flamer probably has tons of respect for you, because he (again, a guy) wants to protect the community he cares for. He's just not seeing the whole picture. So, what you do is tell him that the original flamer has all the rights in the world to speak in the way he wants. If #2 doesn't flame (as in your case), it's harder for the reasons below. 5) let's say you flamed the counter-flamer, this has two consequences: a) the counter-flamer is a little offended but a private email explaining this rational would save his ego and also have the benefit of increasing the trust he has on you as a leader. For sure he will stop flaming, because that's what he wanted to avoid in the first place and calling him on that stops it. b) but more important, the original flaming guy is puzzled. If he was looking for help, he found out that he doesn't have to tone his language, he feels more accepted, therefore less defensive, therefore his language changes and gets easier to deal with. If he was looking for a fight, he knows he's not going to get it here and leaves. Now, the *WORST* thing you can do is to reply this is a flame-free zone. It's very hard to get out of there, because now the guy feels cornered and anything you do in relation to his behavior is going to enforce it. Kicking him
Re: [ANN] Introducing Apache Agora - reloaded!
Will Glass-Husain wrote: Replying to the community list as requested... Thank you. Neat app! Not immediately intuitive as to how to interpret it, but with a little experimentation I could see patterns. For example, it was interesting to notice how my email moved from the outskirts of the circle with data from early months to the center of the circle in later months (for the projects I'm involved with). I'm still unclear on what to look for in terms of community health. eheh, I'm not sure either :-) What are some of the general macro patterns you've seen with this tool? First of all, the 'size' of the pruned graph is generally a good sign because it means there is less chance of a few key players moving out of the project and leaving the social network disconnected. Another interesting thing is that the people at the center are actually the people I expect to be there. In projects that I follow, I was hardly ever surprised: the distance of their node from the 'center of social gravity' of the community was always (and I mean *always*) reasonable. I don't know about the projects that I don't follow, but I've never heard anybody complain. I also found out to be very effective in understanding how much traction/influence a person might have in a community by dragging his node. Sometimes, if more people are involved in a discussion, I pull their nodes apart and see where the center of gravity shifts. Normally the result of the discussion tends to settle toward the person that moved more the graph. This is amazing, because agora does *NOT* even try to understand what the messages say, but only that the message did happen. I suspect there is a deep reason for the apparent incredible signal: in well behaving communities, people do not reply if they don't have anything to say. I suspect Agora would fail miserably to be as effective in disfunctional communities where people keep emailing eachother with flamewars. Luckily, this is rarely the case in the foundation. What insight does this provide into the community? The docs provide a good micro level description of how the app models the relationships between individuals, but don't discuss the macro patterns that emerge. It'd be interesting to hear some of your thoughts. I wrote this years ago, as an experiment. Then I started to use it more and more as a 'telescope' to look at communities that I didn't know, to understand who were the key players in that communities or, if I heard something worrysome about somebody, whether or not to worry that it could have a big impact on a particular community. Unfortunately, this came before the incubator was setup, so the mail archive on nagoya, who was based on eyebrowse, was kinda left alone and a lot of the mailing lists were not there. Some people from the incubator wanted to evaluate the growth of the project with Agora, but they couldn't. There seems to be a lot of information in there. I have my own way of using it but I don't know if it's a general rule and I don't want people to think that their project is better than another just because their graph is bigger or more densly connected. But it is fascinating to compare different mailing lists, especially over time. For example, whether or not 'dev' is more or less densily connected than 'users'. And it's also very useful to understand the 'bridges', the people that write email in more than one mailing list, those are very important people for the ASF, as they bring crosspollination and allow information to flow thru the various islands (and improves our ability to evolutionarely adapt to change in the technical and social ecosystem). It's a social telescope. And normally it's a lot of fun to use telescopes, even if you don't understand everything about the why the stars and galaxies are they way they are. I feel the same way about Agora: you don't have to have a model of what is happening absolutely, as long as you can spot differences between various projects. But I don't know the metric for community health and I don't think such a thing even exists, so if that's what you are looking for, you are not going to get it from Agora (nor anything I do). -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Introducing Apache Agora - reloaded!
Ian Holsman wrote: How would you compare it against Microsoft's Netscan (http://netscan.research.microsoft.com/Static/Default.asp) ? which also tries to find the main contributors in different communities. I think main implies metrics and I really didn't want to go there. I think contribution is inversily proportional to the distance from the center of gravity of the group, but I wanted to keep it subjective to avoid building altars than that people want to fight to step on. Is 'agora' public knowledge? what does the 'decay' area do? How does one differentiate between a useful communication and a flame war? I remember seeing Mark Smith (the netscan developer) talk about how he could identify the different types via the length of the conversation. Overall a big '+1' Will Glass-Husain wrote: Replying to the community list as requested... Neat app! Not immediately intuitive as to how to interpret it, but with a little experimentation I could see patterns. For example, it was interesting to notice how my email moved from the outskirts of the circle with data from early months to the center of the circle in later months (for the projects I'm involved with). I'm still unclear on what to look for in terms of community health. What are some of the general macro patterns you've seen with this tool? What insight does this provide into the community? The docs provide a good micro level description of how the app models the relationships between individuals, but don't discuss the macro patterns that emerge. It'd be interesting to hear some of your thoughts. Best, WILL - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: Apache Committers [EMAIL PROTECTED] Sent: Thursday, July 14, 2005 12:14 PM Subject: [ANN] Introducing Apache Agora - reloaded! NOTE: please excuse the noise if you are not interested, but there is no easier way to reach all of you and I thought many of you might be interested in this. hat type=director mode=off A few years ago, around the time the incubator started to appear as the escape valve for the growth problems that some projects were exhibiting, I started to wonder if there could be a way, for those mentoring and providing oversight for particular projects, to make their job easier, especially if they were not participating in the day-to-day work of the various communities they were helping grow strong and self-sufficient. The task is very difficult, not only due to the nature of the problem (and the unstructuredness of the data), but also about the fact that you don't want to create more problems that you are solving: for example, you won't want people to feel spied or abused by numerical rating and rankings. The result of that thinking was Apache Agora, a system that I designed and implemented 3 years ago and that has been running (quite silently) on Nagoya since then. Since Nagoya is going away, I moved Agora over to minotaur and I have aligned it with the existing mail archive (the same one that we use to power our official mod_mbox based archives). Find it at +---+ | | | http://people.apache.org/~stefano/agora/ | | | +---+ what is this? - Agora is a community visualizer. If you wonder who is the core of a particular community (for example, to know who to ask for something) or how big/active/diverse/balanced a community is, Agora is for you. how does it work? - Agora is composed of two pieces: 1) a python scripts that reads mbox files and generates 'precooked' data 2) a java applet that reads the precooked data and visualizes it the script is running every week (on sundays) on minotaur and it's fully incremental, meaning that knows where it lefts off the week before. how about the network? -- The network is created by harvesting the email addresses and linking them depending on the fact that one address replied to a message sent by another address. I say address because an address is not a person, as there might be several addresses belonging to the same person (and no, the system doesn't (yet) allow different addresses that belong to the same person to be smooshed together) In order to reduce noise, the network is the pruned. All addresses that only received or sent email are removed from the graph. So, the resulting graph is a smaller version of those nodes that exhibit minimal connectivity characteristics (and helps to remove, for example, agents like bugzilla or SVN or spam, that never reply, or lurkers that don't participate in discussions). how do I start using it? The tree on the left lists all
Re: [ANN] Introducing Apache Agora - reloaded!
Stefano Mazzocchi wrote: Ian Holsman wrote: How would you compare it against Microsoft's Netscan (http://netscan.research.microsoft.com/Static/Default.asp) ? which also tries to find the main contributors in different communities. I think main implies metrics and I really didn't want to go there. I think contribution is inversily proportional to the distance from the center of gravity of the group, but I wanted to keep it subjective to avoid building altars than that people want to fight to step on. sorry, hit sent too soon. Is 'agora' public knowledge? no 'private' mail list is being analyzed, so yes, it's public knowledge. it has not been largerly publicized (yet) but I wouldn't be against putting it in a more visible position on the apache.org web site. what does the 'decay' area do? if you do one reply to a message of mine, agora creates a link between you and me of strenght 1.0, then if you do another reply this gets added. Note that links are directional: you might reply a lot to me, but I never reply to you, this is still calculated in the graph drawing algorithm. Decay means that you get 1.0 if you reply now and exponentially lower value if your reply was earlier in time. I introduced this because I was curious about how much the past of a project (especially if you load a lot of months of a project in memory) was influencing its present. Rather surprisingly, decay does *NOT* introduce substantial difference in the way the graph is shaped or the position of people in the graph, which is a very very interesting property and I have no idea why that is the case. How does one differentiate between a useful communication and a flame war? There is no attempt to do, ATM. I remember seeing Mark Smith (the netscan developer) talk about how he could identify the different types via the length of the conversation. As I mentioned earlier, we don't tend to host a lot of inflammatory people in Apache (don't really know why, I suspect is an historical thing or avoiding to react agressively to aggressions, which make flamelovers go somewhere else, but I don't know how to test this hypothesis), this keeps the signal/noise ratio high. Identifying a conversation means that at least *you* can pretend to understand the difference between inflammatory and not. I suspect this difference is also very cultural: a conversation that is a 'normal' tone in one community might be considered very 'strident' in another. I'm sure I'm not the only one who has experienced this. At the end of the day, I'm a big fan of the love/hate hypothesis: replying to somebody indicates a sort of preferential attachment, no matter what you are saying. Ignoring them is the only signal that the communication is not useful. NOTE: I do *not* think that the size of the social cluster is an indication of health, there is something else that influences it... but I don't know what it is (yet). Overall a big '+1' Thanks. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tsunami help] Help somebody find this boy
Noel J. Bergman wrote: Please do NOT send this further: http://www.snopes.com/inboxer/children/hannes.asp The boy was reunited with his family weeks ago. Thank you. And sorry for the noise. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Avalon Closed
Stephen McConnell wrote: -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED] Sent: 21 December 2004 20:22 To: community@apache.org Subject: Re: [ANN] Avalon Closed -BEGIN PGP SIGNED MESSAGE- Stephen McConnell wrote: No policy adopted by a project can supercede the policies of the ASF. Any that do are null and void, or, at best, advisory only. Then clearly you have been negligent in your responsibility towards the Avalon community. No more than, say, the federal government is to citizens of a state when that state passes laws that encroach on federal authority. I.e., not at all. Things stand until they're tested. Bravo, Stephen; you've now competely and utterly convinced me that you're an accomplished troll. It's evidently impossible to hold a reasoned discussion with you. Apparently you're not the least bit interested in Truth; all you're interested in is Being Right. Or so it seems to me. Until you demonstrate that you can at least attempt dispassion and objectivity, I don't intend to waste any more of my time responding to your trolls. Clearly you are not prepared to face up to the fact that the there is a disconnect within the ASF policies and procedures and the functioning of an open community. Clearly you are not prepared, willing or able to address this. You decision to abstain from further discussion within this context is an appropriate move and I commend and applaud this decision. Yes, Stephen, you are right: 9 directors, 120 members, 10 PMC members and 200 subscribers to this list are wrong and you are right. You are so right. Oh my god, you are so right, please, please, take us in your new wonderful world, please, take me with you! I so love your magic wisdom and the fact that no matter what you have an answer for everything and your world is so clean and perfect and shine [john lennon's imagine playing in the back] please, please, take me with you, I was wrong, all of us where wrong... you know how to make software, you know how to make people unite for a cause, you know how to bring money and experience and knowledge to people so that they will be grateful to you and send you good vibes... please, please, don't go away, stay with us, become the Executieve Director and lead us to the next millenium and teach us your wisdom, humility and balance. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Florida election shenanigans caught on tape
Niclas Hedhman wrote: The way you make the bed, is the way you are going to sleep. Niclas, in case you didn't notice, the ASF is *NOT* a democracy. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Organizational analysis of ASF codebases
Dave Brondsema wrote: http://libresoft.dat.escet.urjc.es/html/downloads/woss-icse-2004.pdf I hadn't seen this before; hopefully others will find this interesting also. Hmmm, my day job is about graph analysis and I have researched way to visualize community structure and interaction in the ASF for the last 2 years. Personally, and you can quote me on this, I find this paper very interesting but scientifically shaky. First of all their use of Newmann's algorithm is 'twisted' to say the least. Newman and his assistant Girvan found a method to clusterize community of nodes, not to find a spanning tree between those. The idea of visualizing a spanning tree rather then the entire cluster topology is interesting but might yield to severe artifacts in representation of the relationship information. Second, their use of CVS cross-commits is a very interesting idea, but without taking into consideration mail communication (which is where social communication happens), it might yield to other artifacts. In short, inferring political information (as somebody is already doing) out of such graphs analysis is purely speculative and should be taken with a little bigger grain of salt. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open Source, Cold Shoulder (fwd): One woman's comments
Brian Behlendorf wrote: On Tue, 19 Oct 2004, Julie MacNaught wrote: Conclusion? Just play nice. Right on! It's amazing how well a bit of humility, encouragement of others, and responding to fire with ice works in online communities - whether technical like this one, or social, or whatever. I'm haunted, though, by whether there's a sort of cognitive dissonance in being nice and the Apache name. I'm not suggesting we rename ourselves the Cute Nice Fluffy Bunnies Software Foundation. :) Just wondering if it's something we should overtly work to overcome rather than just inertly hope we aren't setting the wrong tone... Let me remind of when Marc Fleury of JBoss once named us the fat ladies drinking tea while he named the JBoss people the knights fighting the big evil corporations. How many girls does JBoss has? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Open Source, Cold Shoulder (fwd)
Henri Yandell wrote: I'm really not very impressed with the article. case in point? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Open Source, Cold Shoulder (fwd)
Stefano Mazzocchi wrote: Henri Yandell wrote: I'm really not very impressed with the article. case in point? What I mean by that is, look at us, read our style in replying. We like to be slick and sharp, and sometimes email is a form of word-based chess playing made with quotes and (smart) elisions. I looked at LinuxChix.org and, I have to say, seeing all those women ranked and doing some job I think to myself: what a nicer place the ASF will be with some women in the house. I lived with male roomates before and other friends' too: it's just not as good (I live only with roommates from both sexes, if gay even better). It's not about doing the dishes, or about having to take a look at them when they got out of the shower or things like that, is the little touch, the vibe of mutual yet resonating differences in how we perceive reality and how that shapes the environment in a better way. why don't women come in? for the same reason why girls put girls-only on craigslist. A women in an established full-man house will just feel out of place. Oh, yeah, smarty pants, if you read FLOSS it's just about crap? scratch taht surface a little, would you? Now, re-read that sentence. I know Ben can take it. He will probably smile at it. He will probably like me even more after that. Now, imagine the author of that paper reading Ben's comment. Will she take it like that? Sure she doesn't know Ben, she doesn't understand that if he does not say something bad, it means he felt it was good enough. Silence is probably the best complient you can get from him. Imagine living in a house where teh ASF board members lived together. [mental image of stefano running out of the house screaming] Look at us. Yeah, us, alpha geeks! A little flowers on the table might not be enough to get the alpha geek-ness go away, but, know what?, it's not the result (which is going to be pathetic anyway, and they know that already), it's the effort! I really strongly hope that efforts like linuxchix.org take off... in a few years, *we* might be using female aliases to go overthere and be able to start questions without having to spend a few months ahead of time to know enough not to look like idiots (or using the violent tone just to mask our knowledge lacks with arrogance). Or maybe, I'm all wrong. And it's their fault. And we are cool and they are a bunch of losers. So let's go back and play. Where were we? Who's up for a DD game? [sound of stefano scratching ass] -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Board Commentary: Metro and Avalon
Niclas Hedhman wrote: The problem that Nicola perhaps doesn't realize is that, for Apache to be long-term viable, it constantly needs to revive and evolve itself. Otherwise it will become a speck in history, and not a dominant force of horizontal open-source projects. And as you, Ceki, correctly point out, suche evolution is likely to come from a minority and possibly not from the top-tier. I very much agree with that. Unfortunately, what Avalon proposes now is a friction-based style of community development which impedence creates mismatch with the consensus-based style of community developement that is welcome and incubated in all other projects. This impedence mismatch requires continue energy from the top to be controlled. Now the board is left to determine if we want to promote this new style to top level or not and, as a director of the foundation, I have *NOT* seen anything that indicates that this approach works better, or even equivalently well, with the style that we have today in place. If you want to change my mind, that's how you start: tell me what is the benefit for the ASF in promoting this style of community building, despite its long-term history of social energy waste, frustration and contract instability. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: IDE licenses
Brian Behlendorf wrote: Eclipse is open source. Why is this company using their brand? Ugh. And you know what's funny? This company bought its way in the board of Eclipse too. F***ed up might not be right, but it's the first thing that comes to mind. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Policy (Was: Playboy mirror logo?)
Vadim Gritsenko wrote: Bertrand Delacretaz wrote: Le 25 août 04, à 15:53, Sam Ruby a écrit : ...What Jim meant when he said that is that people should STOP saying things like I am begging you!! and God help us all., and START making concrete suggestions on how the policy itself should change... So how about: a) In principle, only logos from IT-related [1] entities are accepted -1. First of all, what's non-IT company's fault so it gets discriminated like that? Are they somehow second class and do not deserve to be mentioned? Second of all, I just don't see any logical justification behind this suggestion. b) Logos from other entities might be accepted if a vote among ASF members is more than X percent positive (suggest 80%) we will take your bandwidth, thank you, but your logo too sucky to be ever shown on our page. That's not the message I'd like ASF to show to the world out there. I completely agree with Vadim. if you don't like to download stuff from playboy.com don't. How hard is that? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inexpensive Lists
Justin Erenkrantz wrote: --On Sunday, July 18, 2004 4:20 PM -0400 Brian McCallister [EMAIL PROTECTED] wrote: I suspect that if 3 ASF'ers want to discuss a topic via email, and think a mailing list would help, there should be a mechanism to simply have it created, bang. Just my 2 cents =) Mailing lists without PMC oversight should be treated with extreme caution. Lists without the necessary oversight might expose the ASF to unwanted liability. The ASF isn't a personal soapbox medium: it's meant to facilitate collaborative software projects. For example, this list (community@) is a *horrible* waste of time that adds little value: almost every topic here has a more appropriate list elsewhere in the ASF (or, ideally, outside of the ASF). But, people seem to use this list as a dumping ground and are often too lazy to think about what the 'proper' list is - instead they just post to [EMAIL PROTECTED] Bitter? Nah. ;-) -- justin I completely disagree with this view. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASF Board Summary for June 23, 2004
Sam Ruby wrote: Stefano Mazzocchi wrote: Greg Stein wrote: * The Cocoon PMC Chair also switched over to Sylvain Wallez, after Steven decided to step down. Steven and Geir are both part of the new PRC, too. What new PRC? Three paragraphs earlier, in Greg's summary: * The Board approved the formation of the Public Relations Committee (PRC). This new committee replaces the Fundraising Committee and also rolls in the responsibility and management of our press activities, public relations, and management of our web sites. The intent is to present a coherent message to the press, our sponsors, and all interested parties. This new committee is chaired by Brian Fitzpatrick. Oh, given the text formatting, I thought it was something related to cocoon. Consusing typesettings, but nevermind. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
Dirk-Willem van Gulik wrote: On Jun 11, 2004, at 2:20 PM, Henri Yandell wrote: 1) Website needs to be in SVN, else we'll still need accounts for everyone who wants to modify their site annd do releases. Are the SVN based projects taking an approach that handles this? Will it? In the company we right now use a small script, triggered by the commmit - which syncs the website up everytime a commit is made to the released branch/tag. curious, why not mod_proxy-it directly? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
Dirk-Willem van Gulik wrote: On Jun 11, 2004, at 10:35 PM, Stefano Mazzocchi wrote: Brian McCallister wrote: [EMAIL PROTECTED] mccallister]$ umask umask 0002 [EMAIL PROTECTED] mccallister]$ umask -S u=rwx,g=rwx,o=rx and set the group sticky bit on the repository home so that group is preserved good hint, thanks. As we had some conflicting requirements we pretty much killed all use of svn over ssh - and forced people to use HTTP/DAV (even on localhost). That solved 80% of those problems :-) can you elaborate more on this? [very interested] -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
Pier Fumagalli wrote: On 11 Jun 2004, at 22:02, Jim Moore wrote: Actually, the all or nothing part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail. Problem being (though) is that I've seen Subversion (1.0.2 under Linux) fail right because of that... Somehow an atomic transaction was left open on the server, don't ask me why... Basically, after that commit failed, the entire repository was so slow that most TCP/IP connections were failing after 3 minutes for timeouts... Only solution was to run a svn recover followed by a svn rmtxt and again followed by another svn recover... I am experiencing random svn corruptions with svnserve over ssh with svn 1.0 (how do I find out the real version btw? why isn't svn -v|--version give me the version?) over linux 2.6.4 any clue? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
Brian W. Fitzpatrick wrote: On Fri, 2004-06-11 at 13:15, Stefano Mazzocchi wrote: Pier Fumagalli wrote: On 11 Jun 2004, at 22:02, Jim Moore wrote: Actually, the all or nothing part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail. Problem being (though) is that I've seen Subversion (1.0.2 under Linux) fail right because of that... Somehow an atomic transaction was left open on the server, don't ask me why... Basically, after that commit failed, the entire repository was so slow that most TCP/IP connections were failing after 3 minutes for timeouts... Only solution was to run a svn recover followed by a svn rmtxt and again followed by another svn recover... I am experiencing random svn corruptions with svnserve over ssh with svn 1.0 Please be careful to distinguish corruption from my repository needs to have 'svnadmin recover' run on it. Could you be running into a repository permissions error? http://subversion.tigris.org/project_faq.html#permissions (how do I find out the real version btw? why isn't svn -v|--version give me the version?) over linux 2.6.4 any clue? 'svn --version' works for me: $ svn --version svn, version 1.0.2 (r9423) compiled Apr 28 2004, 17:16:48 ... hit me with a baseball bat! -- Stefano, crawling back in his corner :-( smime.p7s Description: S/MIME Cryptographic Signature
Re: The Opposite of Incubator
Niclas Hedhman wrote: Hi, At Avalon we have a small problem. Phoenix has ceased to be actively developed, and an external fork has occurred driven by the previous Phoenix developers, called Loom at CodeHaus, and users who needs help with Phoenix are directed to the Loom project. Now, what do we do with the Phoenix codebase in ASF?? GUMP makes this apparent. When changes are made in CVS in projects that Phoenix depends on, we will receive Nags. These are of three types; 1. Temporary and will disappear by themself. 2. Incompatible change in other project, by mistake or un-awareness. 3. Permanent Incompatible change. 1.0 - 2.0 By upgrading Phoenix to these changes, seems fairly meaningless. Killing the Gump descriptor seems like the most logical thing to do, but that would affect projects that depends on it (or other similar cases), James in this case, I think. Should there be a notion of Compost, Graveyard or Retirement Home for projects that has outlived their community? There was a lot of discussion about this at the time of the incubator's birth. It was suggested that anything related to 'death' was a bad idea. JServ is, for example, in dead from a community point of view, yet many people use it in production. JServ is now located at archive.apache.org. If the avalon project feels like discontinuing phoenix, I think you just require a PMC vote and then require infrastructure to seal the CVS repository and put it in the archive. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASF use spamassassin?
Martin Kraemer wrote: On Fri, Apr 16, 2004 at 09:18:17PM -0400, Stefano Mazzocchi wrote: Will the ASF use Spamassassin? But my biggest concern is about false positives. That is why I switched from SA to using *only* bogofilter since last summer. I never regretted it, because the heuristic approach of SA needs rule updates everytime a new pattern arises. (Or did I miss a new SA development?) Well, I still use SA because it is invoked by amavisd, but I ignore its decisions completely (because of the false positives, and because of its suboptimal detection rate overall). that has been my experience as well, but spammers are becoming more creative and they figured a way to make bayesian blind. does anybody know if SA is able to update rules automatically now? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASF use spamassassin?
David Crossley wrote: Noel J. Bergman wrote: Sounds like a *contest* to me! :-) Can anyone (besides Stefano, who's in a class by himself :-) beat my 1,540 references I found 2 unique references for my @apache.org address. I was hoping for none, since I never use it. One is because I simply hadn't noticed that someone had used that address when adding me to a page. The other can't be helped: it is in the KEYS file. You know ... as in: pub 1024D/23CB7A2A 2004/04/17 David Crossley [EMAIL PROTECTED] PGP key servers are also a list of e-mail addresses for spammers. It is a classic isn't it. A search at http://pgp.mit.edu/ for apache does the trick. So we are doomed. Stefano, i notice that you are not on the list. Is that deliberate? no, I just never got serious enough with PGP to actually be able to say this is my key and never felt the urge for it. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Announcing Erathostenes 1.0
Andrew Savory wrote: Hi, On 17 Apr 2004, at 18:59, Stefano Mazzocchi wrote: Find out how this works here: http://www.betaversion.org/~stefano/software/erathostenes/index.html Interesting! But when you say the assumption is that you *never* delete anything ... do you mean in perpetuity? How realistic do you think this is, given the ~40kb payload of most virus mails these days? Over the last 6 months, I've accumulated over a gigabyte of such mail ... that's a pretty high cost in disk space! Or do you discard after retraining? In this version of the script, if you remove an email from the spam folder, the spam database is untrained. This allows you to avoid the escalation of false positives (if you can still spot them!). In the previous incarnation, the script was not doing this, but the problem was that if you had a false positive (or, much more frequent, you moved your ham in the spam folder by mistake and you didn't notice before cron called the trainer) this pollutes the database. In order to be able to perform undo in training (this is not frequent but it's a nice feature) you need to save everything at all time. Actually, the way the script works today is that it makes a local copy of the email in your server, so not only you save everything, but you have two copies of it. Note that it is entirely possible, in case your disk space is limited, to modify the script to remove binary attachments from email. Anyway, In my case, I have 320mb of spam in the last 6 months. Disk space is not that big of a deal these days, especially on servers. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASF use spamassassin?
David Crossley wrote: Stefano Mazzocchi wrote: David Crossley wrote: It is a classic isn't it. A search at http://pgp.mit.edu/ for apache does the trick. So we are doomed. Stefano, i notice that you are not on the list. Is that deliberate? no, I just never got serious enough with PGP to actually be able to say this is my key and never felt the urge for it. Ah, and also that you are using S/MIME not PGP. Sorry for asking silly questions, i am new to this minefield. eheh, it's a field you learn fast, nothing better than some good itches to scratch to stimulate your creativity ;-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASF use spamassassin?
David Crossley wrote: Stefano Mazzocchi wrote: snip/ But my biggest concern is about false positives. One solution would be to use spamassassin for tagging purposes only, but at that point it's much better to let people do the filtering themselves. There is no reason in wasting precious CPU power for that. A more socially-acceptable compromise would be to leave the threshold level of the cutoff point to the various people to set (you could set a .spam_threshold file in your home directory with the cut-off point). So, if you keep the threshold low and complain, well, that was your own fault. I would prefer to see server-side filtering because i don't want to even receive the volume of junk. It is a big waste of precious bandwidth. True, but keep in mind that you can still do server-side filtering, just you have to do it on your own (as I do already today, for example). Surely we can tune SA to minimise false-positives, especially since we have the experts themselves at Apache. Being an expert in pattern matching doesn't make you an expert in understanding what is spam or not for somebody. My point is that no matter what, there is only so much you can do on a centralized spam filter and you should not, IMO, attempt to do to much. That's why I think leaving the threshold configurable by person is the best approach since it leaves you the ability to turn the nob in how selective your filter is. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASF use spamassassin?
Antonio Gallardo wrote: Stefano Mazzocchi dijo: David Crossley wrote: Surely we can tune SA to minimise false-positives, especially since we have the experts themselves at Apache. Being an expert in pattern matching doesn't make you an expert in understanding what is spam or not for somebody. AFAIK, if anti-spam expert existed, the SPAM problem will be solved years ago and this is not the case. People is trying to find the anti-spam solution. The progress in the area is good, but nobody found the right solution. I personally think the one (or team) who will solve the anti-spam problem will be part of the computer history for ever! Sometime I found you very reluctant to some technologies. Please look around and you will find that spamassassin is the best we can have right now in anti-spam technology. This is not casuality that many companies are building anti-spam product using spamassassin to stop spam around the world. Currently, spamassassin is scaning millions of mail per day and is sucessful in that: http://wiki.apache.org/spamassassin/CommercialProducts And we (on the ASF) are discusing right not about if will be fine to eat our own food. :-( I didn't say we aren't not going to use it. I just said that given the size of the email traffic and the variety of people (almost a thousand) that this move will impact, the ASF infrastructure team is considering this with great care and, as usual, doesn't want to rush things, but try to do them right. Besides, there is no hurry since, as I said, you still do all you want from your end without impacting everybody else. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Announcing Erathostenes 1.0
My email address gets 3,820 references in google. Security by obscurity doesn't work, nor fighting spam via obfuscation. My counter indicates 4534 spam message since monday. Of these, only 45 reached my inbox (and half of those are those damn Vicodin strains! grrr) Of all the 27000 spam messages that my spam repo has, I was not able to find a single false positive in the last 6 months. Find out how this works here: http://www.betaversion.org/~stefano/software/erathostenes/index.html Hope this helps. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASF use spamassassin?
Antonio Gallardo wrote: I just hope soon the spam problem will find a final solution. The final solution is to render it obviously ineffective and this battle is done on your end. Why do you think google gives you a Gb-worth of storage? so that you don't delete anything. Why that? have way more subsymbolic semantic data to train their networks, so that not only they can be the best search engine, but also the best spam filter in the world. I've been doing this myself for more than a year now and I could not imagine a world without this, it would be impossible for me to find a single email in the pile of shit I receive. The hope is not that spammers will go away, but that those who *pay* them for spamming will find the thing so ineffective that will put them out of business. And you win this battle only with with better content-based filters, not obfuscation, nor whitelists, nor blacklists. Or you make sending email more expensive or you have authorities regulating digital identies. But those might create more problems than they solve. What we need is a web of distributed identity control. But that's the hardest thing in the history of technology applied to society. Luckily Apache hosts a few people that have been working extensively in the area... so well, something might turn out from that too. For now, I just filter the hell out of them ;-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Mailing lists hiding sender's address?
Ceki Gülcü [EMAIL PROTECTED] wrote: Your comments are welcome. If you pick 10 people and ask them, you come up with at least 20 solutions for spam and 100 ideas. I think email obfuscation is just as useless yet appealing as security thru obscurity if the amount of email obfuscated is high enough (and apache produces tons of it). We can pick n random obfucation methods, but this will make the job just n times harder and I don't think we can come up with more than, say, 20 meaningful obfuscation methods. Another idea is to remove the From: header entirely. This way, you don't know who sent the email, nor spammers can. But this will totally destroy the mail list ecosystem. Your proposal of using bogus address looks appealing at first, but it potentially makes the problem even worse: it might be a worm sending you that message, pretending to be me. Net result: Ceki is now (involuntarely) spamming Stefano. Note that if this method was institutionalized, you need rebouncing prevention (my bogus address spamming your bogus address and ping-pong forever). I am strongly against any system that bounces email and my 300 spam/bounces messages a day prove why [ and I can't estimate how many don't even reach my inbox due to @apache.org prefiltering ] -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Adding Stefano's How it Works! paper to Apache web
Dirk-Willem van Gulik wrote: On Apr 4, 2004, at 4:14 PM, Phil Steitz wrote: After forwarding the whitepaper version of Stefano Mazzocchi's Apachecon 2003 session on How the ASF Works to several people interested in learning about Apache, it occurred to me that having this content somewhere easy to find on the web site would be a good thing. So...with Stefano's permission, I converted the pdf to xdoc and submitted a patch here http://issues.apache.org/jira/browse/INFRA-56 I included a patch to add a link to the new page off of the Foundation menu. Both the formatting and placement are just initial suggestions. If others think this is a good idea, we can reformat / pull apart / relocate in whatever way makes sense. Nice ! Very Nice ! I have received a lot of positive comments on that content and I'm very happy (and proud) that Phil took the time and effort to do this. I would be honored if that became the official document on the ASF. I also received a bunch of suggestions mostly from Ben and Jason (here copied because I'm not sure they are subscribed here). I hope they chime in. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache should join the open source java discussion
Costin Manolache wrote: Serge Knystautas wrote: Leo Simons wrote: Key ASF individuals are joining these discussions, on weblogs and various discussion forums. But the ASF as a whole is silent. In lieu of forming a statement for the ASF as a whole, what about organizing/encouraging/guiding people who want to participate? Maybe specific resources that should be targetted, such as where the most active and/or productive discussions are taking place. What about starting by making sure Apache java projects _do_ work with the 2 open source JVMs that are mentioned in the article ? That would be a statement, much better than we like open source java, but our software doesn't run on it because it doesn't really matter. Nobody has been stopping you from proposing an incubation project about this. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache should join the open source java discussion
Geir Magnusson Jr wrote: On Mar 18, 2004, at 7:10 PM, Stefano Mazzocchi wrote: Costin Manolache wrote: Serge Knystautas wrote: Leo Simons wrote: Key ASF individuals are joining these discussions, on weblogs and various discussion forums. But the ASF as a whole is silent. In lieu of forming a statement for the ASF as a whole, what about organizing/encouraging/guiding people who want to participate? Maybe specific resources that should be targetted, such as where the most active and/or productive discussions are taking place. What about starting by making sure Apache java projects _do_ work with the 2 open source JVMs that are mentioned in the article ? That would be a statement, much better than we like open source java, but our software doesn't run on it because it doesn't really matter. Nobody has been stopping you from proposing an incubation project about this. Why would it be an incubation? Because all new project have to go thru incubation to get up to speed. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache should join the open source java discussion
Noel J. Bergman wrote: What about starting by making sure Apache java projects _do_ work with the 2 open source JVMs that are mentioned in the article ? That would be a statement, much better than we like open source java, but our software doesn't run on it because it doesn't really matter. Nobody has been stopping you from proposing an incubation project about this. Why would it be an incubation? Because all new project have to go thru incubation to get up to speed. What new project? I didn't see one. I don't think Geir saw one. All I saw was a notion that existing projects would test with other JVMs. This could be done by each project that cares to do it, and perhaps GUMP could do it for all. And, by the way, outside projects enter the ASF through the Incubator. I don't believe that anyone has ever said that if, for the sake of argument, Cocoon wants to build a new Flash-based webapp framework, that it needs to start it in the Incubator. Did I miss a memo? No, you are both right, it's me misunderstanding Costin's comments. Apologies, I need a brain transplant soon. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache should join the open source java discussion
David N. Welton wrote: Brian McCallister [EMAIL PROTECTED] writes: I suspect that getting a consensus from the ASF members, much less the community at large, as to a stance on open source Java will be pretty difficult. The ASF is made up of individuals, not a small number of which are intimately involved with each of the major JVM providers. Is anyone actually against this? I would find that disheartening. I think a simple, general statement would be a good contribution: The Apache Software Foundation would like to add our encouragement to the parties looking into open sourcing some or all of Java. We are in no way opposed to the existance of proprietary software, but in our years of experience working with open source infrastructure, have come to recognize that having the basic building blocks for some of our most successful projects be free would be of enourmous benefit to all involved, both individuals and corporations Or something along those lines...short, sweet, not asking, but suggesting. I would totally give my +1 for something like this. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Renaming package names
Nick Chalko wrote: Ceki Gülcü wrote: In one of my current projects I have come across some 3rd-party commercial product, that they have renamed the package-structure (from org.apache.log4j to com.COMPANY.org.apache.log4j) - just wanted to know if this does not violate the Apache Software license? I think bea, does this. It is one way of ensuring that bea will use exactly the version of log4j they want without naming/classpath confilts. I think it is fine as long as the NOTICE with attribution to the ASF is left. java (unlike c#) does not have a versioning concept for classes so many people are resulting in changing package names to do exactly that and make sure that you don't trigger class cast exceptions during classloading. [cocoon is currently voting about doing the same on the other side, changing the name of the rhino packages to avoid collision with rhino shipped with weblogic and websphere] also, keep in mind that there is nothing in the license that stops people from changing package names. You could think that the use of the name apache and log4j in the package name would be considered abusive, but this would result in them changing the name entirely and this would not solve any issue. In short: if they give credits, they are in good faith, if not, no matter what they do with the software, they are abusive... but package name change should not be considered abusive as such, but rather a necessity that arised out of java internal limitations. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Subversion 1.0
Jeff Trawick wrote: Sander Striker wrote: On Thu, 2004-02-26 at 21:02, Noel J. Bergman wrote: Is SVN being proposed for Incubation? I hadn't heard. SVN is built on top of APR, and also implements an Apache module (mod_dav_svn), so it already uses a lot of ASF code. That said, it would totally rock if SVN would come to the ASF. well put!! I wonder how the SVN community would feel about this. Greg, do you have any idea? what would be your opinion about this? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [kfo...@collab.net: Subversion 1.0.0 released.]
Greg Stein wrote: fyi... - Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] Subject: Subversion 1.0.0 released. To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Mon, 23 Feb 2004 04:24:55 -0600 (CST) Reply-To: [EMAIL PROTECTED] Subversion 1.0.0 is ready! It lives! :-) Finally, I must say [with all due respect, that is] ;-) Awesome! More than anything, I strongly hope that means that the protocol is stable. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASF Board Summary for February 18, 2004
On Feb 23, 2004, at 10:05, Dirk-Willem van Gulik wrote: On 23/02/2004, at 3:55 PM, Stefano Mazzocchi wrote: Greg Stein wrote: ... It's amazing to see how the foundation, despite it's growth, is still flexible enough to make serious decisions in changing old habits and past mistakes. This is all very refreshing. Thanks ! Great work guys, I'm proud. :-) Ha! :-) :-) But no amounth of flattery is going to keep you safe - one day we will finally find a way to see you shanghaied and tied up onto a board seat.. :-) :-) Damn smart kids! :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: planet aggregation doing some editing?
On 9 Feb 2004, at 10:04, Brian McCallister wrote: On Feb 9, 2004, at 9:50 AM, Rodent of Unusual Size wrote: the style attribute is dangerous? absolute positioning, maybe. with color. I remember somebody (norman walsh?) showing how you can change the meaning of a page by injecting style that could color words in a sentence white on a white background, then rearrange the words around and make it look like a totally different sentence. pretty clever hack and for sure not that portable with current state of CSS selectors support, but in the future, well, that's something to be really concerned about in general. but for this particular case, style is no danger since it's embedded and come from the same source. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Location for syndicated Apache blogs
On 8 Jan 2004, at 19:38, Ted Leung wrote: Next someone will insist that this has to go through the incubator. LOL -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community *thanks* and Community *responsibility*
Tetsuya Kitahata wrote: Hello! Now I am exploring about our brains. :-) left-side cerebral cortex (A) | right-side cerebral cortex (D) --|--- left-side limbic system (B) | right-side limbic system (C) (A) can be expressed as Calculation Brain (B) can be expressed as Organization/Planning Brain (C) can be expressed as Communication Brain (D) can be expressed as Innovation/Integration Brain (A) is opposed to (C) as well as (B) is opposed to (D). The confrontation between (A) and (C) can be expressed as the difference of men/women. (Just a difference of the preference of thinking) (B) brain often takes responsibilities of local organization (and person). Also, (B) brain is highly related to sectionalism, bureaucratism. (Bureaucrats often create trifling works in order to maintain their *local* organizations and keep their prides ;-) On the other hand, (D) brain (as opposed to (B) brain) can also take responsibilities, however, they would be rather global responsibilites. I imagined these *responsibilities* can be highly associated with community thanks. When I became Apache Software Foundation Committer, I felt strangeness of the messages Thanks/Sorry from some ASF members. I tried to confirm what makes them say such words in particular situations. Now, I do realize that this was Community thanks/Community sorry. ( = These *thanks* messages are derived from the WILL of our community) Yes, I have come to realize and now feel these Community Thanks/Sorrys very comfortable. Also, I can proudly say that Thanks, Apache. Maybe, this is one of the most important factors by which Apache attracts a lot of developers and users from all over the world. Also, as I've read the bylaws of the ASF, this bylaws seems to have affinity to these kinds of Community Thanks/Sorry/Responsibility ... really nice. ... What do you folks think? What is this community thanks/sorry thing? and what does this have to do with the brain stucture you describe? Excuse my evident stupidity but I don't get it. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transition of the subscribers to announce MLs
On 1 Dec 2003, at 22:55, Tetsuya Kitahata wrote: On Mon, 01 Dec 2003 11:40:21 -0600 William A. Rowe, Jr. wrote: If you want to avoid offense, a much better term for your efforts (and more recognizable in the western open-source world) is evangelism. And those evangelism efforts from you, and many folks who champion the foundation and the ApacheCon show, are always appreciated :-) Aha... Okeydokey, I've already known the term evangelize and it's common in japan, too. I did not know that this word can be used in the western open-source world. I imagined that evangelize/evangelist could be used only by me and Stefano ;-) # Evalgelion -- The title of the famous Japanimation. To contextualize a little: Tetsuia and I had a few private conversations about differences in culture between Italy and Japan (also, the are also amazing similiarities... don't forget that WWII was Germany+Italy+Japan vs. rest of the world, definately not something to be proud of, but nevertheless interesting to understand how it could came to be) During these conversations, I expressed my long-time fascination for the japanese culture and society that, I believe, was transmitted to me thru anime (I basically grew up watching anime) and more recently mangas. BTW, the complete title is Neon Genesis Evangelion and I believe it's, by far, the best robot anime ever. If you can, watch it. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: Talk about ASF
On 28 Nov 2003, at 09:57, Sander Striker wrote: On Fri, 2003-11-28 at 08:28, Avik Sengupta wrote: Hi, I have been invited to give a talk on the Apache Software Foundation at the Linux Bangalore/2003 (http://linux-bangalore.org/2003) which bills itself as India's premier Linux/OpenSource event. I hope to give the audience an idea of what the ASF community is all about. A brief outline of my thoughts for the talk is at http://www.sengupta.net/pages/ASF.html I would be keen to get some advise from folks here.. what are the attributes of our community you would highlight at events like this. I suggest you have a chat with Stefano, who did a talk at the ApacheCon this year about the structure of the ASF: http://www.apachecon.com/2003/US/html/sessions.html The second plenary on monday. Find the presentation here http://www.betaversion.org/~stefano/papers/AC2003-ASF.pdf and the whitepaper here http://www.betaversion.org/~stefano/papers/AC2003-ASF-slides.pdf feel free to use. Ciao. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: Mailing from apache email address
On 7 Nov 2003, at 23:25, Brian Behlendorf wrote: Therefore, you have one other option involving SSH, but allowing you to use your local mail client. Minotaur.apache.org is configured to allow SMTP relaying via the localhost interface. So what you do is set up an SSH tunnel that connects your own localhost port X (X can be any value above 1024) to minotaur's localhost port 25; then in your mail client configuration, you set your SMTP server to be localhost, port X. When you send a message, your mail client will connect to localhost:X, relayed over your SSH connection to localhost:25 on minotaur. I do this, though not with apache.org's server. Uh, didn't know that minotaur allowed that. You learn something new every day ;-) -- Stefano, who likes to have several options when email is concerned - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inappropriate use of announce@
On Tuesday, Oct 21, 2003, at 07:03 Europe/Rome, Craig R. McClanahan wrote: Tetsuya Kitahata wrote: On Mon, 20 Oct 2003 08:02:35 -0400 (Subject: Re: Inappropriate use of announce@) Rodent of Unusual Size [EMAIL PROTECTED] wrote: tetsuya has a lot of energy, and i think we are seeing the common decay into inertia and conservatism common to groups as they grow and age. imho, we should work against this tendency, and seek to empower people (or at least help them find appropriate ways to use all that energy) rather than stifle them with policies and bureaucracy. Thank you :) The only two ways to avoid bureaucracy are : * Accept the difference, heterogeneous ways of thinking with each other (with RESPECT) * Invite Innovative-Mind guys/ladies constantly Innovative (half of the computer engineers have such a mind) way of thinking can be easily in opposition to that of Conservative. This is explained by the brain (In these cases, right-cerebral brain and left-limbic brain) mechanism. Bureaucracy is highly tied up with left-limbic brain. Also, bureaucracy is one of social-diseases, which are curable by no means. Bureaucrats tend to hide their asses, possess the instinct of self-preservation, and highly show the self-defense mechanism when attacked by innovative (non-conservative, liberal) ones. # Self-Defense Mechanism can be perceived by very funny # reactions of the bureaucrats. Very Funny, Indeed. The matter is worse, those who are genuine :) bureaucrats can not assay themselves as they are suffering from the disease of bureaucratism. This (bureaucracy) can be found here, there, everywhere in japan :) Incurable serious disease of the society... As if we are awiting the collapse to death of our social system within a few years. well well, you are just going too far here, IMO. One thing is being rude and non diplomatic. An entirely different thing is to be a part of a serious disease. sad. Even more sad that you can see the similarities, but not the differences. When I apologized it was because of the tone of the discussion and because the discussion took place in the wrong location (when foundation-wide entities start to deal with merit issues, the entire foundation looses the ability to increase its diversity, thus to adapt better to a changing environment) Now, you want the system to adapt to you, but how much are you going to adapt to the system? Calling the ASF beaurocratic shows only how low your ability to understand and adapt to a much more complex system is. This is understandable, but not excusable as a reason to resign. [you can just say sorry, I'm tired or have no time for this and that would be a perfect reason to resign, but that's another story] Tetsuya, Like many others here, I definitely appreciate your contributions on the Apache Newsletter. It has been a task needing to be done, but nobody previously was willing to put in the energy and enthusiasm you have shown to actually make it happen. But I would like to point out something you *might* not have given enough weight to in your own thinking -- cultural sensitivity is a two way street. One of the hardest things for many newcomers to Apache (or other open source cultures that operate similarly) is the brusque-sounding tone of many comments. It's not personal -- it's based on a (shared) goal to improve things, not necessarily (or even usually) intended to shut things down. There are more than a few times when I've come close to saying to heck with this place due to criticisms of my actions that I took too personally; but not doing so was one of the best things I ever avoided doing. Your comment about bureacracy is interesting. For the first time in my life, I've spent the last three+ years working for a big company (Sun), after working for organizations with 500 employees previously in my career. Apache's bureaucracy doesn't hold a candle to Sun's :-). Nor, from what I gather, does it compare to most other big organizations either. In fact, the real problems I see for Apache are almost the opposite. It is the *lack* of a final authority making decisions is what causes most of the conflict I see. True, but for deity;'s sake, I wouldn't want to change!!! As a wise and effective politician once said democracy is a terribly poor form of government, but every other one is worse. The meritocratic system we use has its own defects and it's questionable if it can scale more without collapsing on its own weight (due to its inverted top-bottom flow of control), but any other form of government would possibly induce higher efficiency, but lower our ability to adapt and diversify. In the case at hand, you ended up reacting to one person's statement. That person did not speak for the Board or the Members; he spoke for himself. I personally doubt if his opinion was, or is, even a majority view of whatever constituency you consider to be the Apache community. And, the fact that the previous
Re: Inappropriate use of announce@
I don't want to drag this along forever, but I feel I need to be
precise because I don't want email communication to make it drier than
it is.
On Tuesday, Oct 21, 2003, at 09:07 Europe/Rome, Tetsuya Kitahata wrote:
On Tue, 21 Oct 2003 08:52:16 +0200
Stefano Mazzocchi [EMAIL PROTECTED] wrote:
When I apologized it was because of the tone of the discussion and
because the discussion took place in the wrong location (when
foundation-wide entities start to deal with merit issues, the entire
foundation looses the ability to increase its diversity, thus to
adapt better to a changing environment)
Stefano, to tell the truth, what made me sad was
the apologies from you at [EMAIL PROTECTED]
You, announce@ moderator, should not have apologized because
you were *not* guilty. What made me angry and sad was
not the TONE of the controversy at [EMAIL PROTECTED]
Rather, what I did (publish the newsletter) let
you apologize to the other people.
I understand and respect your feelings and positions, but I also would
like you to know that I was not sad, nor angry, just disappointed by
what happened over at [EMAIL PROTECTED]
This discussions seems to be touching several human sides and it's
probably getting bigger that is should be, but there are a few things
that were realized:
1) infrastructure@ should deal with infrastructure issues *only*. the
decisions to use announce@ for publishing the newsletter should *NOT*
have been discussed on infrastructure and any decision taken by them
without a reasonable infrastructural concern should be void and
overruled.
2) open source communities tend to be aggressive environments. I don't
know if this is because we have our hearts on our keyboards as Ken
poetically phrased ('poetically' intended as a compliment, not as
ironic criticism), if because email is such a poor communication media,
if we use a common language and native speakers tend to forget the
impedence mismatch with non-native speakers, if we haven't seen in
person before, a lot of potential reasons.
NOTE: #2 is, IMHO, the reason why women cannot stay in an open source
environment for long. Women dislike aggressive environments by nature.
3) burn-out happens. I have been burned out twice and in both
situations I left for a while. As long as one year at one point. All
the people that I know and learned from all burned out, some left for
some time, some left entirely.
4) the more the foundation grows, the harder is going to be to change
something. this appears as beaurocracy, but it's not, it's just social
inertia and it's not as bad as it seems because it keeps thing sane.
Yes, I knew that you did really take care of the
mood of community and i suspect that you apologized
because of it. However, it made me sad at the same time.
You shouldn't be.
I felt I had to apologize because when I consider myself part of a
community or team (not that I'm consider myself part of
infrastructure@, i'm just a stupid lurker there with no sysadm skills
whatsoever), if one makes a mistake, the entire community makes it.
I don't think David and Sander did such a bad thing, they expressed
their opinion, but I disliked the way they did and I wanted to
apologize for the feeling you got out of this.
You felt sad but they probably felt angry at me because of this, but,
if they did, they didn't express it publicly.
As you see, there are many sides all the time and it's really hard to
find a balance.
It takes respect and a good dose of patience and ability to digest what
you dislike and simply pass by without taking it personally. And,
believe me, this is an art on its own and crosses cultural borders to
reach the limits of wisdom.
...but I'm getting too philosophical, I think, so I stop here and just
respect your choice.
Calling the ASF beaurocratic shows only how low your ability to
understand and adapt to a much more complex system is.
No, I did not declare. I am now talking about the
*beaurocracy* with the people in japanese government.
Most of my juniors (Kouhai) / seniors (Sempai) are
government officials.
That's it.
Oh, then if I misinterpreted your comments. Sorry for that.
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get pgp keys signed
On Wednesday, Oct 15, 2003, at 23:31 Europe/Rome, Ben Hyde wrote: - ben (who thinks that the web of PGP signatures doesn't grow because people can't figure out the rules and are embaressed to admit it) ..or they haven't been given a reason to care. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get pgp keys signed
On Thursday, Oct 16, 2003, at 18:56 Europe/Rome, Ben Hyde wrote: Stefano Mazzocchi wrote: Ben Hyde wrote: - ben (who thinks that the web of PGP signatures doesn't grow because people can't figure out the rules and are embaressed to admit it) ..or they haven't been given a reason to care. My dear friend Stefano - go ahead, pull my cord, bait me, tease me... yep, that was the goal! :-) Hot button: How to make your community more action oriented: Don't focus on motives for actions, focus on barriers that prevent those actions. There is a wonderful bit of psych research on this. They were attempting to see if people[1] were better motivated by reason or fear. So they made two pamphlets, one explained the benefits of testing for STDs and the other painted a horrific picture of the consequences of going untreated. Much to their frustration the behavior of the students was mostly indistinguishable. Both approaches resulted in some increase in the desired behavior. But this is the important bit. They then made a 'slight' modification to the pamphlets. They provided directions on how to get to the clinic along with it's hours of operation. This single change made all the difference. - ben :-) [1] undergrads actually. Point taken and understood, but ask yourself: would have they gone to the clinic if they didn't know what a clinic was? If somebody doesn't know what difference does it make to have a key signed or not, why would he/she want to go thru it? Before giving the clinic hours of operation, you should at least tell them what a clinic actually is for, no? -- Stefano, crypto ignorant but fascinated by it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Web Of Trust, was Re: [FYI] Apache Agora 1.2
On Monday, Oct 13, 2003, at 15:35 Europe/Rome, Ben Laurie wrote: Speaking of which: where's those t-shirt designs, dammit? I would gladly to the graphic design part but don't have any idea on what to write on it :-( -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[FYI] Apache Agora 1.2
It's with great pleasure that I announce the availability of Apache Agora 1.2. Find it over at http://nagoya.apache.org/~stefano/ [NOTE: the location has changed since last version!] Unlike previous versions where dataclouds were generated by a script and simply visualized by the application, with this new version, you can play interactively not only with the graph, but changing it directly from the application. In the above location you find an instance of agora running as an applet (NOTE: you need Java 1.2 or above to see it!) and connecting to the Apache mail archives hosted on Nagoya. Agora runs a preprocessing scripts over the entire eyebrowse archives every Sunday morning (Pacific time) understanding which mbox files were modified and reprocessing only those who need reprocessing. You can also download a distribution to run the visualizer and the script locally on your own MBOX files. See the README.txt file included in the distribution for more info on how to do this. The changes since version 1.1 are: o) Added the ability to zoom into the graphs by right-clicking (or control-clicking for single-button mice) and show the labels of the nodes closeby (they are drawn radially from the mouse location to reduce label overlap). o) Moved the datacloud aggregation and processing into the application. This allows a nicer usability of the tool so that users can create dataclouds on the fly using preprocessed mailbox information that can be published on the web. o) Added the ability to introduce time-based link decay which simulates the fact that the importance of a reply decays with time. o) Modified the mailbox processing scripts to produce message data instead of dataclouds. Message data is fetched by the application to produce the datacloud according to the selection of the processed message archives that the user selects. o) Improved the overall prettyness of the drawing by extensive use of Java2D functions like rounded rectangles and transparency. The overall drawing performance has been reduced, but there is the ability to turn off part of the drawing to improve performance. o) Introduction of a grouping capabilities that draws circles around the nodes that participated in a particular community. This allows better identification of the 'node clusters' which belong to different communities. - o - Agora will be presented in detail at my Virtual Community Dynamics at ApacheCON 2003 As usual, feedback, is very welcome. Happy playing! :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Newsletter Draft] News from YOUR PROJECTS in July, 2003
On Friday, Aug 1, 2003, at 15:01 Europe/Rome, David Reid wrote: Can we move discussions about newsletters to another mailing list? I know I'm not alone in finding that while some here will be interested, many aren't interested in assisting though will happily read the finished results. Regrettable? Certainly. Why not add a newsletter@ mailing list and those that feel they have literary bones can join there and contribute towards the newsletters production, then once it's ready and available it can be announced on announce@ (and possibly here as well). Life is too full of emails that can be considered spam already and I'd rather not add to that pile with messages (however well intentioned) about newsletters and the administration thereof. what happend to the tune please not yet another mail list? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MailAlias.txt
On Tuesday, Jul 22, 2003, at 23:41 America/Guayaquil, Tetsuya Kitahata wrote: Hi, I put the text file named MailAlias.txt on the committer module (on the top directory). USAGE: [EMAIL PROTECTED],[EMAIL PROTECTED] [EMAIL PROTECTED],[EMAIL PROTECTED] . The aim of this file is to make AGORA stats more precise. I created this file for the purpose of making stats on each mailing lists (fantastic!) via my favorite mail client soft originally, however, I thought that this could be used for AGORA, too. Please feel free to add your e-mail alias or modify this file. Wonderful!! I'll patch agora to include this information ASAP. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache Newsletter [Re: Jakarta Newsletter Issue 9 -- May-June 2003]
on 7/11/03 6:07 AM Thom May wrote: Why the obsession with email? push vs. pull example: we are having this conversation and the information I'm sending its pushed into your mailbox. I could post this information on a weblog and then point you to it, but, in my experience, the chance that you will read it is much lower. another reason is asynchronicity. if I push it in your mailboxes, you carry it with you. maybe on a train, as it was already noted. Sure, you can download stuff from the web and carry it with you but it *requires* effort from your part. Again, the chance that you will do it is much lower. This is what I would like to see: 1) the ASF publishes a newsletter (following the very nice style used in the recent Jakarta one) that covers all the ASF endevours. Including infrastructure, licensing, security, incubation and all the non-so-project stuff. 2) the newsletter is sent to announce@apache.org 3) the newsletter is then archived on www.apache.org/newsletter/[date] What do you think? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Newsletter Issue 9 -- May-June 2003
on 7/10/03 4:21 PM Dirk-Willem van Gulik wrote: ... one of the consequences of encouraging the breaking up of jakarta is that there are a lot more apache projects (whether they started in ... if we do manage to get some momentum for an apache-wide newsletter, would Please please ! I think that none of us works in a vacuum across artificial boundaries. Virtually all systems I build at work or for play, mix and match things; a bit of XML here, some application language there, perhaps some java left, somea bit of apache to connect it safely to the internet; some PDF generation to keep PHB's happy, etc, etc. XML, web and java are rarely separated; WS and ant straddle half our world - t is hard to think of any app server environment whilst ignoring bits of php or mod_perl, etc, etc So an apache-wide newsletter would be great. And posting it to apache wide announce, or even xposting it to all announce mailing list - sure. I'd love that. Having it on the web is nice for archival too - but I certainly do not mind 5-25k of well written quality newsletter (like the recent one, or like apache week) delivered to my doorstep. Keep up the good work - and think broad - there are no real boundaries in the ASF, except for those we invent ourselves. I can hardly agree more with Dirk's view. I think we should have an apache-wide newsletter and deliver it thru announce@apache.org once a month. At apachecon one of the most packed sessions is always the explaination about all the different projects in one confy session. This newsletter tells people about the status quo without having to shop around for info. I think it would be a great tool to increase crosspollination and awareness even for people inside the ASF (me first!) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WORA Considered Evil ;-)
on 6/27/03 5:37 PM Steve Brewin wrote: - the chance of a JVM exploit. - potential exploits via native code in a JDBC driver. - the use of native code in matchers/mailets, e.g., the anti-virus matcher. --- - the use of third party matchers/mailets. - the use of user-defined scripting matchers/mailets - support for SOAP - one pipeline being extra busy or big performing lots of processing and/or handling large messages, should not deny service to other users. I remain unconvinced that all of the issues are potential security risks, but as I tried to say in an earlier posting, its a matter of trust. Many java programmers are used to think that being so abstract from metal, a java JVM is instrinsically more secure. It is true that the usual types of attack like buffer overflows just don't make any sense (unless they attack the native libraries underneath, but even that is hard) and that the JVM security model is very well designed (they choose security over performance and it's a choice that, IMO, paid well, .NET does the other way around and we'll see what happens) At the same time, imagine taking all sendmails of the world and substitute them with what James right now, how long would it take hack into it? I would suspect a few weeks. Yeah, it's a matter of trust and it's because of paranoia that trust is created because it's a catch-22 cycle: - sysadm are paranoid (irrationally so, so forget about changing that) - sysadm with big load and with a system that works, won't change it because of architectural elegance, you need functionality: they look at security, performance and ease of configuration/use (in that order) and 99% of them stop there - performance can be effectively measured, ease of configuration/use can be tried and appreciated (although irrationally as well, so be prepared to do stuff that *they* are used to, not stuff that you think they should be learning to do! this is the key to usability: adapt the system to users, not the other way around) but... - security cannot be measured, it's a matter of trust. I'll tell you a story: Apache JServ is still considered today one of the most solid, scalable and lightweight servlet engines on the market. So much so that Oracle still ships it in their AppServer. Well, we *never* were able to convince the Apache sysadms to install it on apache machines. Why? at the end, I think, it was lack of trust. On java, on java on freeBSD, on the load consumption, on the memory consumption, I can't really tell you what it was, but, reality is that it never happened. is there an *real* reason for that? I don't think so. but we are humans, we have feelings and we have fears. If you don't design a technical system taking ease of use and the users' fears into consideration, you are doomed to failure in aquiring a good and diverse community of users. Reading your post that dismiss the UNIX sysadm fears as a think of the past, remind me of the discussion Pier and I had when we thought about the exact same thing of Brian's (for us, excessive) concerns on java. Today, after being involved in infrastructure@ for a while (just lurking, I'm not even close to be decent enough as a sysadm to help them), I can tell you that it's exactly this get modern and stop the crap approach that is hurting java and stopping it from becoming mainstream in main fields. I might be wrong, but I blame it on WORA. I'm really happy to hear Noel having a much more down to earth approach to the problems, it will give James much more chances of being appreciated by a much wider audience. And this was the reason why I started talking about this. You can argue all day about the technical reasons why those fears are unjustified, but fears are not objective: there are aereonautic engineers who are afraid of flying. From a purely rational point of view, it should be impossible, but it happens. Pier is a world-class java programmer and earned this merit by participating in writing some of the best java software available on the market. Still, and maybe because of this, he doesn't trust it as much as it trusts other software or, let's put it this way, doesn't trust the WORA-injected syndrome that everything should be run inside the JVM. I heard rumors that many of the Solaris engineers in Sun think exactly the same about java, but they are silenced by the company. Go figure. So, at the end, while I agree with you that some of those fears are technically hard to justify, the only objective part is that they exist. You can choose to ignore them, but in doing so, James will just never exit the cool concept stage it has been in since its creation. I believe there is critical mass for this project to exit that stage and enter the next phase where it really starts eroding marketshares of other mail servers, but the mindset of its developers must exit the 'go pure and screw their stupid fears' because it's not
Parrot [was Re: How ASF membership works and what it means]
copying the cocoon folks since we are getting pretty serious with continuations overthere (we implement them using a modified version of Mozilla Rhino, a javascript engine written in java) on 6/26/03 3:15 PM Ask Bjoern Hansen wrote: On Thu, 26 Jun 2003, Santiago Gala wrote: [...] I still feel shocked when I (rarely) see a JavaVM crash with a seg fault (out of memory always, maybe some beta JDK at times). The safety of the JavaVM contrasts a lot with the dangers of C/C++ environments, and makes it compelling to write a java alternative even when good native libraries do exist. This is the viral character of it. I wonder is parrot will do the same for perl/python/ruby. I think it has always been true for those languages that people often choose to reimplement something in that language instead of wrapping a C module. Some of the big things that Parrot hopefully will bring are: easy interop between languages that are targeted to the parrot VM (use Python and Perl libraries in your BASIC program) Shared VM development between the various dynamic languages instead of having everyone roll their own as it happens now. yeah, this is a cool thing and it's impressive to note that almost all modern programming languages are moving (one way or another) the VMS way of bytecode compilation for a virtual machine. (even XSLT stylesheets are being compiled into bytecode) Dan Sugalski wrote an article about why we can't just run Perl, Python or Ruby on the JVM or CLI: http://www.sidhe.org/~dan/blog/archives/000151.html - ask ps. http://oreilly.com/parrot/ was the April Fools joke, http://www.parrotcode.org/ is not. :-) Wow, a VM with native continuations, very interesting. Question: do you think it would be possible to compile java source code into parrot bytecode? how would the limited Perl typing capabilities would impact that? I feel like crosspollinating these days ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java + Scripting languages
on 6/27/03 5:58 AM Sam Ruby wrote: Sometimes it sucks to be four years ahead of your time. Amen. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WORA Considered Evil ;-)
on 6/26/03 8:03 AM David N. Welton wrote: Glen Stampoultzis [EMAIL PROTECTED] writes: Yes. As dogmatic as Sun has been about pure Java it's still a success factor in the adoption of Java. There's still no other platform out there that makes it as easy as Java to write for multiple platforms. Errr... really? Glen is talking about the JVM, I suspect, more than the java language. This is in line with things like Jython and PHP5 being all compiled to java bytecode. It is even more so in .NET where the CLI virtual machine has been designed to be similar to a modern high-end processor, not as a microwave oven microcontroller one (as, unfortunately, it is the case with java, where the JVM architecture sucks ass). And exactly for this reason, if Mono is successful and doesn't get locked by Microsoft legal battles and Sun doesn't open up the JVM, we'll simply write a compiler from JVM to CLI and simply mix the best of both worlds, escaping, at least, vendor lockin from the JVM part and hopefully removing some of that holy WORA syndrome that is really stopping people from thinking about the fact that diversity is good for you and doesn't necessarely prevent portability. BTW, Glen, HTTPd is written in C and it's *by far* more portable than any java program out there. At the same time, the amount of work done to allow this portability is impressive, while, compiling for a JVM, gets you instant portability and almost no cost. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How ASF membership works and what it means
on 6/26/03 6:46 AM Santiago Gala wrote: Stefano Mazzocchi escribió: on 6/24/03 6:59 AM Dirk-Willem van Gulik wrote: I think that we have multiple subcultures under the ASF umbrella, due to the way that the umbrella projects were formed. Whether you like that or not, I think that is the reality. I know that I personally would And I think that is a healty thing. It makes us more resiliant and self supporting in a changing world. I certainly do not thing that 'enforcing' the patterns of 'httpd' are a good idea. I agree, also because I'm not so sure that the patterns of httpd are necessarely the best ones. I believe that the java.apache.org-originated culture of a lower bar for committership created the explosive growth of jakarta and xml. Something that the HTTPd culture fails to identify as a value, but it might well be from a purely darwinistical perspective, because it allows more noise and mutations to enter the system, thus improving the ability to adapt to environmental changes. This, I think, is the other side of WORA at work. Your criticism of it does not show that WORA (or, really, the Java VM architecture) allows for a lot more safety to experiment than native architectures. I still feel shocked when I (rarely) see a JavaVM crash with a seg fault (out of memory always, maybe some beta JDK at times). The safety of the JavaVM contrasts a lot with the dangers of C/C++ environments, and makes it compelling to write a java alternative even when good native libraries do exist. This is the viral character of it. Hey, don't forget that, despite my criticism on the java monoculture, I remain a java fan. I just opened up my views to other languages (expecially scripting ones) since I think that java falls short in many situations. I wonder is parrot will do the same for perl/python/ruby. uh? wasn't parrot an april's fool joke? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java + Scripting languages
on 6/26/03 7:55 AM David N. Welton wrote: Hi guys, I saw this: http://www.jcp.org/en/jsr/detail?id=223 The specification may include a Java API that can be used, possibly through JNI, by an scripting language engine to access the desired Java objects. Can anyone give us a more concrete description of what this is really about? From where I stand, it looks like the JSP folks changed gears in their marketing engine. Now they want to make it easy to move millions of PHP folks into the J2EE. It looks interesting, because... hey, who wouldn't want to associate with a million dollar marketing machine:-) Yeah, that's exactly how they are going fishing for new market opportunities, so you wait for them instead of doing your own stuff and you get locked into their politics. I heard rumors that PHP5 might be (partially) compiled into bytecode, with JNI hooks to existing php libraries, or, on the other hand, use JNI hooks to access the servlet API exposed objects. btw, our good old Sam Ruby showed it's already possible both hooking from java to php or from php to java. Code is already into PHP and there was a time where you could write an XSP page for Cocoon using PHP as a scripting language (but nobody cared and the code died) At the end, I will not be surprised if this turns out to be yet another JSP-like political compromise between vendors, with no technological value associated to it. [note: I was part of the JSP JSR and asked to be removed exactly because I couldn't stand their political-driven design attitude.] Sorry to sound cynical or rain on the party, but I lost hope in the JCP (or all committee-driven design, for that matter) a long time ago and it's simply getting worse. My point is: you can hook to java *right* now, if you care (look at Sam's code in PHP if you want to see how). JNI is there and it's all you need. It is true that a *common* native abstraction for hooking into scriptable java objects would make it much easier to hook different scripting languages to the java platform (today, you have to do everything by hand for every language you hook), but then again, it's nothing that is not already possible. Hope this helps. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WORA Considered Evil ;-)
on 6/26/03 11:28 AM Stefano Mazzocchi wrote: So, we created the Mailet API and started JAMES, later we had Federico involved that did most of the coding. The above is not painting the picture correctly. Federico did the POP3 server and the first Avalon integration, while Serge did the SMTP part (including DNS lookup and all that). Serge has been the real driver of the JAMES project since the beginning. Pier, Federico and I were just instrumental in getting the concept in java.apache.org and inject a little vision on the mailet concept. But James has been a real community development and we have pretty much nothing to do with what James is right now. Serge infinite much more credits than we do. Apologies for not having been precise. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How ASF membership works and what it means
on 6/24/03 6:59 AM Dirk-Willem van Gulik wrote: I think that we have multiple subcultures under the ASF umbrella, due to the way that the umbrella projects were formed. Whether you like that or not, I think that is the reality. I know that I personally would And I think that is a healty thing. It makes us more resiliant and self supporting in a changing world. I certainly do not thing that 'enforcing' the patterns of 'httpd' are a good idea. I agree, also because I'm not so sure that the patterns of httpd are necessarely the best ones. I believe that the java.apache.org-originated culture of a lower bar for committership created the explosive growth of jakarta and xml. Something that the HTTPd culture fails to identify as a value, but it might well be from a purely darwinistical perspective, because it allows more noise and mutations to enter the system, thus improving the ability to adapt to environmental changes. The problem was, IMO, that this growth was not identified early on and this lead to the creation of somewhat balkanized subcultures, which we (ASF) are now trying to reduce by allowing projects to autogovern themselves and escape the umbrella. But again, only if they like so, because freedom of choice is key in a healthy and respectful organization. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How ASF membership works and what it means
on 6/21/03 11:01 PM Thom May wrote: * Stefano Mazzocchi ([EMAIL PROTECTED]) wrote : NOTE: copying members@ and community@ since this might be helpful to many people. Stefano, this was a really well written piece that, for me anyway, explained perfectly the difference between committers and members and what the process was for moving from one state to the next. Would it be possible to put this under the foundation site somewhere? Thom, as I wrote inside my email, while the description of the process is more or less objective and it can well be placed on the web, the value of membership is only my own personal view and it's not a vision shared by the entire group of members. But I believe that the meaning of membership will be a hot discussion point in the future and, as we come up with consensus, I'll be happy to describe it and place it in a public location. Thanks again, and thanks to everyone for granting me the distinct privilege of being a member of the ASF. Welcome on board! ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How ASF membership works and what it means
on 6/23/03 8:42 AM Dirk-Willem van Gulik wrote: On Mon, 23 Jun 2003, Steven Noels wrote: Stefano's insightful post got me carried away to run some stats on members projects: http://blogs.cocoondev.org/stevenn/archives/001008.html I've always stopped short of doing just this; and more kept things limited to a pie diagram and postings/#of commits. This as it mostly shows 'today' rather than the members body which grew over time and is effectively lagging. I.e. you are looking at data which tells you more about history than about the future. And that todays future is tomorrows history. Dirk is right pointing out how a specific frame in time tells you the 'position' but not the 'speed'. Luckily, social dynamics don't exhibit the Heinsenberg principle. Please comment if you care, but keep the thread on community (or cocoon-dev). I'd love to hear your opinion. My main interpretation is -We are tremendously dynamic in terms of ratio's and relative numbers; things turn upside down regulary. Yeah, in analysing dynamics, change in time cannot be overlooked. -xml and java are 75% of the activity; the 'old school' has dropped below 20% now (Ignoring PHP here). -Despite the enourmous influx of java and xml the ASF as a whole is growing significantly slower than the internet. This might not be as bad as it seems: you fail to note that the growth of the internet is *not* necessarely the same growth of its technical side. When a technology matures, the growth indicates adoption, not necessarely increase in social technical substrate. I think the social technical substrate is growing much slower than the internet in general. And it might just be the same growth that we exhibit. Which would be totally fair. [no numbers to prove this, nor any idea on how to get those numbers] -Documentation is growing even slower; even including translations. *this* is a problem. I'm currently spending all my research effort to overcome this. I think it's entirely possible. -Organisationally xml and java are still lagging behind; but have been catching up (though the catch up has slowed down somewhat due to a much larger influx from the old school side; and that influx is by average younger than the proposed influx from xml and java (in terms of lines of code and/or years of activity on *MORE* than one project). the inertia of the foundation is big. but things are slowly moving. I expect more stabilization and new top-level projects in the future. this will help uniforming the foundation and participation. -Java (and to a lesser extend xml) is _actively_ under represented and produces less orgaisational/infrastructure/legal people than one would expect given the current relative number of existing java/xml folks in organisational positions. That may be a cultural thing. could be. could also be lack of information or lack of social contact with other parts of the foundation. In my todo list I still have some plans to increase the power of Agora as a community microscope. -In the java, and to some extend the xml world, we have much, much much more code which was only touched 1-4 times by = 2 people over time. this is another problem and, IMO, it's a cultural thing as well: java people tend to like to reinvent the wheel, just because coding in java is easy and the WORA religion is a powerful engine. -the java world seems to need amazing number of indians (or committers) relative to lines of codes or bugs fixed. And seems to see more isolated pockets of people than the xml and other parts of the ASF. I don't get what you mean here, can you elaborate more? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How ASF membership works and what it means
NOTE: copying members@ and community@ since this might be helpful to many people. As many of you know, three cocoon committers were nominated then elected members of the Apache Software Foundation yesterday. Since I've been inquired by a few on how the system works, I'll spend some words on the process and what it means for me. Note: there is current a debate happening inside the members of the ASF on the value and meaning of ASF membership so, please, don't take my words as the ASF truth (if there is one), but just as my personal opinion on this matter. Now, for the objective things, here is how the process works: 1) any ASF member has the right to nominate an ASF committer for membership. 2) when such nomination is done, a few sentences have to be provided on the reason for the nomination, for example, explaining what they have done for the ASF and why the nominator thinks that they have the skills/will/behavior required to be an ASF member. 3) in the past, a nomination required to be seconded by another ASF member. This is no longer required (am I right on this?), even if highly welcomed by the members because it indicates some level of agreement. 4) every 6 months or so, the members do an election. In the past, the elections were done physically and synchronously. Today, we have a digital voting system which works like this: a) if you are eligible to vote (you are a member and you are not emeritus), you receive an email with a number that uniquely identifies your vote. b) you connect thru SSH to cvs.apache.org and use the tool on /home/voter/ to vote, using the number that identifies your vote along with the vote content. c) the vote takes a time span (normally one or two days), you can vote as many times you want and the last vote is the one that counts (previous votes are overridden). d) votes are then counted. results shared to the members list (which is a private list where only ASF members can read/write email) and the elected people are informed and asked for participation. Members have access to all election data, so a member is able to find out who nominated him/her and who seconded. Votes, on the other hand, are secret and remain so, even for members. - o - Now for the value of ASF membership. The chain of merit inside Apache is: user - committer - member - everybody can be a user - users who care about a project are elected as committers - committers who care about the foundation are elected as members It is hard to nominate a member, much harder, IMO, than to nominate a committer. Why? well, because it's easy to understand if somebody cares about a project (they submit code, they participate in the community, they do stuff and get to be known), but it's much harder to know if someone really cares about the foundation, because normally they don't do much for the foundation if they are not made members. Kicken-egg problem. There are great committers who can be terrible members. And regular committers who can be incredibly good members. A committer that works on more than one project and takes cross-pollination and community building practicesa in great consideration, makes a great candidate for membership. A committer that evangelizes about the apache spirit, that cares about community dynamics, that tries to help other apache communities, makes a great candidate for membership. But since I value membership so much, I personally have a pretty high bar for membership (this is not shared by other people and others projects inside the ASF, but I don't see this as a problem because respecting differences is what makes us stronger and able to learn) and this is why it takes years for me to nominate somebody for membership. Now, what is a member? A member is a shareholder of the foundation. Basically, it's part of those who own the foundation and are able to effectively decide how the foundation works and, for example, where it spends its money. You want to make an official apache conference? the members decide how and who should. You want to have our servers hosted in a location that we own instead of sharing bandwidth with a corporation that can cut us off at any moment? the members decide how, where, how much we can afford to pay for it and so forth. You have an idea to promote the foundation or to do something new and marvellous? the members decide what to do. Also, remember that members nominate the board of directors who are the one that run the foundation in all those daily details that most of us don't see and take for granted. Yeah, all of this is still, in perfect apache spirit, a volunteer job. This is the reason why committers are nominated, then elected but it's still a personal choice if they want to participate or not. Becoming a member is not only a great personal achievement, but it's also a responsibility. A responsibility in front of those committers, those people, that you are going to represent with your
apache.org vs. mozilla.org
Recently, I've started to dive into mozilla with a developer eye. *very slowly* since my c++ skills are almost non-existant (and my c skills are, h, rusted and ruined by the java garbage collector :-) Anyway, the cultural differences between their style of development and ours are striking. 1) they have *ONE* big CVS module where all developers can commit to anything. I believe this is a *major* mistake because devs have to download the whole thing in order to build mozilla. the communicator philosophy was attached to their very mindset. also notice that the mozilla CVS module is 650 Mb (as of yesterday), this rules out almost all dialup or pay-per-minute fee users. Which means, in the last 5 years, probably 80% of the potential non-US developers!!! While DSL is changing this for europe and other first-world nations, this is not so for the rest of the world. with smaller and more manageable CVS modules (and nightly snapshots to route around CVS firewall restrictions), *our* potential dev pool is orders of magnitude bigger than theirs. 2) tinkerbox is a nightly build system which aims to improve continuous integration by forcing everybody to commit to the same tree. I think this can't scale as much as we can with a Gump-like approach. The continous forking friction (chimera, phoenix, minotaur) is tearing their communicator-inflicted mindset apart. Rightly so, IMO. The more diverse the development community becomes (and this is slowly happening, also, maybe, because of increase on european broadband), the more the community will look for 'KISS' solutions that are driven by lazyness and 'getting the job done' by small incremental steps. In this new mindset, their infrastructure will have to change significantly to adapt to this. 3) mozilla.org doesn't have the concept of separate 'users/dev' forums [see below why I call them 'forums']. This means that development is mostly done internally, or privately. Most available forums are equivalent to our 'users' forums where power users post questions on use and simply don't care about the internal development. I believe this sums up the problem of acquiring new developers: people are rarely sucked in and they don't get to 'know' and appreciate the developers by listening to their dev-oriented conversations. Star stages are bad, but visibility is the way people pay back. having a mozilla.org account is not seen as valuable as having an apache.org account. why? well, because all netscape people got one for free! there is no clear meritocracy and this means no clear visibility value since there are no mozilla stars. not even as a group. nothing. This is emerging now with the smaller projects like phoenix and camino and minotaur where a few people really drive the show and earn their merit and create envy in others that want to be part of that show and feel cool. ego is an incredible motivator for geeks. only recently mozilla.org has understood a way to make good use of it and this is stop forcing everybody in the same room and see what happens. [even the ASF is doing this by promoting projects in top-level domains and this is a good thing for both, IMO] - o - Now, there is one difference that puzzled me. In mozilla.org, forums are newsgroups. In apache.org, forums are mailing lists. Yes, I'm aware that it's possible and quite doable to automatically map one into the other (and sites like GMane do already for some of our lists), but I think the differences might be a lot more important. Worth discussing the differences: 1) the ASF has human spam filtering, mozilla.org doesn't. This shows. The amount of spam in their newsgroups is, well, irritating even if not very high. This is clearly a plus for our approach. 2) mozilla.org is archived at google groups. this is clearly a plus for their approach since our mail archiving and indexing capabilities, well, suck ass compared to theirs. (no offense for the eyebrowse people, just stating reality) moreover, google groups archives the entire history of the internet. From an historical perspective this is going to be incredibly important (and another reason to worry about google to be the next microsoft/AOL big-brother-wannabe, but that's another story) 3) mail clients have newsgroups-advanced features that are normally lacking in mail folders. For example, autotrimming forums to, say, the last 500 messages. (please don't tell me how smart is your client or your solution to do it anyway: my point is that newsgroups and NNTP were *designed* for forums, while email was designed for point2point communication and clients reflect these mindsets) also the need for mail filtering is a lot decreased (again, don't tell me how you do it because I don't care) 4) for newsgroups, lurkers can read archives from their favorite mail/news reader. for mail lists, they have to use web-based intefaces. This is, IMO, a *HUGE* plus for newsgroups. - o -
Re: apache.org vs. mozilla.org
on 4/5/03 4:22 PM Glen Stampoultzis wrote: At 11:15 PM 5/04/2003, you wrote: Recently, I've started to dive into mozilla with a developer eye. *very slowly* since my c++ skills are almost non-existant (and my c skills are, h, rusted and ruined by the java garbage collector :-) Anyway, the cultural differences between their style of development and ours are striking. Have you talked to them about this. No, and this is exactly the point: I don't know who to send it to! post it on their 'general mail list' seems a bit ackward. Posting it to their 'board-equivalent' too much high. they don't have community@apache.org or [EMAIL PROTECTED] ! they just have newsgroups for users and everything that happens behind the scenes. Sure this might well appear the same about the ASF from the outside, but I found myself with no reference. Any suggestion? The comparison could be very interesting/useful to them. I would love to see mozilla.org and apache.org crosspollinating more. It can only be useful for the web. Leading web Server and web Client open development communities unite to keep the web open! That would make a great story, wouldn't it? :-) But, IMO, this shouldn't happen *from the top*, but from the bottom. Too bad that their skills/programming-languages are almost orthogonal to the ASF's ones. :-/ We host just two C++ projects and all of them have been donated and are maintained mainly by corporate sponsorship (and would probably die in a few seconds if they stopped supporting them) Actually, the bigger overlap between the ASF and mozilla.org (despite the dependency on HTTP, of course) is done by, guess what?, Cocoon which is actively using Rhino as the engine for its continuation-based web application framework. Too bad rhino is a satellite of the mozilla.org world since java counts almost nothing there (and for a reason, I would add), in fact, it's rhino that doesn't really fit to mozilla.org, IMO. Anyway, I'm very interested in both Minotaur (the factored out mail client, which indeed rocks even at 0.1a state!) and Midas (the iframe-based inline editing component). I'm seriously thinking about working to add serious contentEditable= operativity to mozilla and this will require pretty hard work inside the trunk. I might eventually be able to get commit access in order to maintain it and that would be pretty cool. but all this depends on many variables about my workign future so don't hold your breath or take this as a promise :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
talking about privacy
I started looking up a bunch of US people I know and I found this: http://preview.ussearch.com/preview/preview.jsp?adID=10002101fc=NCSHORTx=0y=0searchFName=SamsearchMName=searchLName=RubysearchCity=searchState=searchApproxAge=40 Gosh, Sam, you really look younger than your age ;-) Anyway, such a site would be *SUPER ILLEGAL* in europe and, I'll tell you what, my gut feeling is that I'd really like it to remain so. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Scrambling jar files?
I just ran into this and found that might be worth injecting into the jar repositories discussions. http://nbbuild.netbeans.org/scrambler.html -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
Jason van Zyl wrote: Or how about we make a tautalogical resolution like the Ant or Cocoon resolutions which got passed. I'm fine with changing the resolution to something like those of Ant or Cocoon: The Maven Project will deal with the Maven system. FYI, the ASF Board stated clearly that this 'recursive nature' of the Cocoon Resolution is a problem and that they expect the Cocoon PMC to fix this ASAP. -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[fyi] apache ego massage
http://java.sun.com/features/2003/02/britannica.html -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the artistic license and ASF code - okay?
Henri Gomez wrote: FYI, Cocoon ships with Jetty built in. Never tried to bundled with Tomcat ?) No, Cocoon is big enough already. -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build systems vs. license issues [Re: Hashing it out ...]
Sam Ruby wrote: Justin Erenkrantz wrote: I believe the FSF has an ulterior motive for keeping the Java situation quite murky. -- justin I'd like to caution you against attributing motives to other's actions or inactions. I'm not making this suggestion with any official Apache hat on, but based on my experience that such statements rarely lead to productive consequences. As for me, I would like to observe that we have the public statements made by the FSF, including the text of the GPL license. We have the knowledge that this issue has been around for a long time and has never been resolved. And we know that that people like Brian have invested a fair amount of time on this topic. What I conclude from this is that it would be both difficult and unlikely for a successful resolution of this issue. Despite the fact that quite a number of us (myself included) would love to see this resolved. As Santiago hints, I bet Mono will lead the way for this. We care to have this resolved, but it's not vital to have the FSF flag on our camp. For them is a different story (even if, they already released their libraries using the MIT license and RMS wasn't pleased, to say it midly) -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Morgan Delagrange wrote: OK, Java-specific question. It seems likely that altering or inlining LGPL code pollutes the Apache license. Are you of the opinion that IMPORTING but not altering or distributing LGPL classes pollutes the Apache licecnse? And if so, can that be stated on the Wiki page? If LGPL code cannot be imported, it's pretty much useless in any capacity for Java projects. Bingo. The only *reasonable* way of dealing with LGLP stuff would be thru some for of reflection (reflection, for those who don't know, is the ability for java to connect to 'named' resources of classes. it's the most *dynamic* form of loading for a language which is already entirely dynamically loaded). So, suppose that LGPLObject is there somewhere in your classloading space (the classloader is the virtual machine subsystem that looks for your classes, classes being the objects and main units for java programs, all classes are always dynamically loaded) and this LGPLObject contains the method (java terminology for a function) called doSomething() If you use *regular* programming practices you have to do import LGPLObject; then LGPLObject o = new LGPLObject(); o.doSomething(); that will 1) ask the classloader to find that object 2) allocate memory for it 3) create the object 4) invoke the object method doSomething This means, mostly, for legal sakes that the LGPLObject *MUST* be in the classloading space during compilation time. Now, if we use reflection, we can do Class c = Class.forName(LGPLObject); Object o = c.newInstance(); Method doSomething = c.getMethod(doSomething); doSomething.invoke(); which compiles even without having the LGPL library in your classpath. *BUT* programming java in this way is *FOOLISH*. Reflection was created to load classes programmatically at runtime, it was not created as a way to route around legal problems. -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Santiago Gala wrote: Stefano Mazzocchi wrote: Morgan Delagrange wrote: OK, Java-specific question. It seems likely that altering or inlining LGPL code pollutes the Apache license. Are you of the opinion that IMPORTING but not altering or distributing LGPL classes pollutes the Apache licecnse? And if so, can that be stated on the Wiki page? If LGPL code cannot be imported, it's pretty much useless in any capacity for Java projects. Bingo. The only *reasonable* way of dealing with LGLP stuff would be thru some for of reflection (reflection, for those who don't know, is the ability for java to connect to 'named' resources of classes. it's the most *dynamic* form of loading for a language which is already entirely dynamically loaded). So, suppose that LGPLObject is there somewhere in your classloading space (the classloader is the virtual machine subsystem that looks for your classes, classes being the objects and main units for java programs, all classes are always dynamically loaded) and this LGPLObject contains the method (java terminology for a function) called doSomething() If you use *regular* programming practices you have to do import LGPLObject; then LGPLObject o = new LGPLObject(); o.doSomething(); that will 1) ask the classloader to find that object 2) allocate memory for it 3) create the object 4) invoke the object method doSomething This means, mostly, for legal sakes that the LGPLObject *MUST* be in the classloading space during compilation time. In legal terms, your program will not build without a class named LGPLObject which has a public doSomething() method. Incorrect: it will *build*, but it will not *execute*. So, you *depend* on it. In a sense, with import you're stating dependency in your sources. True. This is the reason why this legal route-around will not work against GPL, but only against LGPL. Now, if we use reflection, we can do Class c = Class.forName(LGPLObject); Object o = c.newInstance(); Method doSomething = c.getMethod(doSomething); doSomething.invoke(); which compiles even without having the LGPL library in your classpath. In legal term, again, your program will *behave differently* if a class named LGPLObject exists in your runtime environment and it happens to have a doSomething() public method. With dynamic loading you're not stating dependency, merely *acknowledging existence*. This accademic trick is done to prove there is a way to totally isolate the virality of LGPL in Java (at least, that's my personal opinion). I think it would be pretty hard to state that my program can be considered part of the LGPL-ed library if I call build it even if it's not even present on my disk. As the concept of derivative work is about something that extends or change a preexisting work, the second approach will probably skip it (specially if your program tests for the result of the snippet code and survives when the given class is not in the path). Exactly. I don't think that even reflection will stand in court if your program cannot perform its duty without the given library being there. I.E. fine when alternate services can perform a task, or for non-essential components of a project. Again, you are not taking into account that I working again the LGPL, not the GPL. There is no way to route around GPL. It was very carefully designed for that purpose. *BUT* programming java in this way is *FOOLISH*. Reflection was created to load classes programmatically at runtime, it was not created as a way to route around legal problems. +1 disclaimer type=IANAL ditto. Also, I am just a plain committer, so take it as just my opinion. /disclaimer let me state again that I consider this discussion pretty accademic (there is no way in the world I would suggest going down the reflection path to use a LGPL library... it would be much easier to rewrite the damn library or convince the author to change the licensing!) Still, I think we need to sort out all possible cases since they're going to come up again in the future. -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to place Agora?
Ben Hyde wrote: So one possible awnser to the question is: check it into committers someplace and see if you can get a community to begin to emerge. The privacy issues can be used as cover for not going more public at this stage :-). what about using the /community CVS module instead and move Krell into that as well? -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine neccesitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to place Agora?
Santiago Gala wrote: There is potentially a huge value in fostering research on data emergence, expecially if related to reasonable-sized and well logged communities like ours. The map experiment (the bulb could bright or be coloured according to data collected) would be easily linked to Agora, bringing additional spacial and day/night information into play at a glance. Wild! crosscorrelation between 'virtual distance' (calculated thru agora) and 'physical distance'... h -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine neccesitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where to place Agora?
Hello there, I've received many personal comments about my little thing Agora (for those who missed it, go to http://cvs.apache.org/~stefano/agora/) and I have already received comments, suggestions and patches (a PHP script that harvests NNTP newsgroups instead of mbox files) Now, I'd like to ask you what I should do with this. People suggested that Agora could be used as a tool to visualize any type of massively interconnected graph (from personal relationships, to hyperlink tolopologies, ontologies and what not). People suggested ways to improve the visualization. Others suggested ways to improve the algorithm of energy minimization (I spent a good night with Ben Laurie in London talking about the use of symulated annealing and other symulated entropy-based thermodynamic approaches) All I know is that if the code remains on my disk, they will ask me and I'll be the bottleneck. so, I wonder, should I go down the path of 'incubation'?, should I move it under the committers/ CVS? or in the community CVS? move it on sourceforge? should we clutter this mail list or should we ask for another one? just like this community enjoyed the fun brought back by Ben on the map of committers, I would like to bring some fun back with Agora, but I'm asking because I really don't know on how to move from here. Thank you. -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine neccesitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open community (was ... secret discussions ...)
Joshua Slive wrote: Ben Hyde said: Didn't we settle this most contentious issue some time ago with a few megabytes of text and a long complex vote coupled with a solid turn out? If so it's painful and cruel to reopen the issue. - ben I've already apologized twice for rehashing an old issue, but that is obviously a penalty a list must pay if it has no archives. True. In fact, this list voted to have a public archive in place. The fact that such archive is not existing is merely a do-ocracy issue: nobody cared enough to create the archive. From what I've been able to glean from people's selective memory and mail quotes, the lack of archives is simply an oversight. What that tells me is that there was never an intention to discuss anything private on this list. Rather, the purpose of closing this list seems to have been intended to keep out unwanted opinion. I still find this repugnant. Look again. The intention of the people who voted to keep it closed is to keep the signal/noise ratio high enough so that people can cope with it. I will reiterate my arguments, then I'll go away for to save you all the pain of my opinions: 1. The list is, at minimum, terribly misnamed. The Apache community consists of more than just committers. The majority of the people which are interested (quite a lot, that votation was the most voted poll in the entire history of the foundation) voted to keep it closed to try to improve the signal/noise ratio but also recognized the necessity to make available to the public the entire discussions so allowed a public archive to be available. What about the thousands of people who have made substantial contributions to Apache by submitting important patches, filing detailed bug reports, answering questions on users lists, etc? You can guarantee that many of these people have contributed more to Apache than many committers. 2. Excluding outside opinions hurts us all. It limits our perspective, it inhibits the recruitment of new participants, and it makes us seem like a bunch of stuck-up cool kids who just want to keep to ourselves. And no, allowing invited guests does not eliminate either problem. I'm not sure this is the type of community that I want to participate in. CVS repositories are open for read and closed for write to people who deserved that right. This is an ASF-wide community mail list. It's open for read (just didn't happen yet) and closed for write to people who deserved that right. Since we have CVS and mail list oversight on code and we can always roll back, we could, in theory, let everybody write on CVS and filter them out later. We could apply the same policy here. Since the ASF decided for closing down the CVS repositories and filter people *before* they are given the ability to modify the code, we are applying the same pattern here. Please explain why you find this pattern 'repugnant' on a mail list, but you don't on a CVS repository. -- Stefano Mazzocchi [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[announce] Agora 1.1
I'm very proud to announce the availability of Agora 1.1. This improved version includes a totally rewritten datacloud visualizer (written in Java since Dynamic SVG was *way* too slow for the purpose). It runs both as an applet and as a command line application. The tool includes enough documentation to get you started and use the tool yourself, including some pregenerated dataclouds to play with the visualizer. Get it from http://cvs.apache.org/~stefano/agora/ Comments, questions and any kind of feedback will be very appreciated. Thank you. -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: python foo (was: email notification done...sorta)
Greg Stein wrote: But out of the box? Python has multidimensional arrays. Not sure what you're smoking :-) I said *better* support. I didn't say that Python doesn't support them. The creation and manipulation of multidimensional arrays was the only thing I found to be cumbersome and harder than in java, until I found Numberic Python which does have a bunch of API that help you a lot with those. But at the end, I was able to go around the problem myself. Just took a while. In fact, there are a couple of requests for enhancements on python.org exactly about this so I assume I'm not the only one who had this problem. Ah, btw, yes, I'm not sure about what I have been smoking either :) -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: email notification done...sorta
David N. Welton wrote: Noel J. Bergman [EMAIL PROTECTED] writes: I'm going to be curious to see how Subwiki works out -- if the intent is to switch --- being in Python, not Perl, but still not in Java. Are there more Python coders than Perl here? Anyone can code in Python. It's easy, and it runs anywhere. Not quite an offer of help, but... if you have figured out one programming language, picking up Python will not be hard, nor unpleasant. That's been my experience... but python really needs better support for multidimensional arrays :-) or merge numeric python in the default language. But anyway... -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: fyi wiki statistics
Greg Stein wrote: On Tue, Jan 07, 2003 at 05:08:19PM -0500, James Taylor wrote: You are stating that: 0) download a working copy [this is done only once] 1) go to a page 2) edit it 3) save it 4) commit the page is comparably simple with Feh. I said no such thing. I said that if you wanted to do multiple page edits without spamming the change-notification mailing list, then SubWiki makes it possible [by following the steps you suggest]. In no way did I say it was comparably simple to standard Wiki editing. Of course not... jeez, just how small do you think my brain is? :-) Sorry, I clearly overreacted. Apologies :-) 1) go to a page 2) edit it 3) save it and I disagree. If it means I can edit the page in my fancy editor of choice rather than a dumb web browser then it is much simpler. And standard tools and standard commit emails and standard access control and all kinds of other stuff. Point taken and appreciated. The (only?) beauty of a wiki is its dead-simple editing cycle. I believe sub wiki also has a TTW editing interface. No reason you can't have both. Because it uses subversion to hold pages, the interface is nicely seperated from the data store. Yes. You definitely cna edit pages via the web site. That *is* what a Wiki is all about. Not the stupid formatting rules. http://test.webdav.org/wiki/Welcome And both is actually incorrect. You have four ways to view the content and three ways to edit the content: 1) read/write via the Wiki itself 2) read/write via working copies 3) read/write via WebDAV (new from sussman and jerenkrantz) 4) read via web browser This implements separation of concerns and everybody knows I'm happy when I see that :) Sure, it is not ready for primetime, but I like the idea a lot. The code is ready, but I don't have all the standard formatting rules and macros in there right now. There are a number of things that people expect which just aren't in there. This is not a problem as I think people might add those if needed. And Python is much easier than Perl for java people anyway :) -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: email notification done...sorta
Andrew C. Oliver wrote: -jAndy.pl.NET ROTFL :) -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: Tapestry incubation
Eric Dobbs wrote: On Monday, January 6, 2003, at 02:35 AM, Henning Schmiedehausen wrote: My only concern is, that we will spread a limited number of developers over too many projects. The developers and their communities are already spread over those many projects. As Jim wrote: (communities are what really matter, not code.) Over time (maybe lots and lots of time) cross-project pollination does happen here in Apache land. Two years ago when I got started with Turbine I remember there being animosity toward Avalon and Inversion of Control. Now Turbine developers are warming up to Avalon. Let time and proximity do the hard work. Amen, brothers. -- Stefano Mazzocchi [EMAIL PROTECTED]
CPAN for java [was Re: RSS feed for ApacheWiki now in beta test]
Dirk-Willem van Gulik wrote: On Thu, 2 Jan 2003, Danny Angus wrote: Invent a CPAN style method of satisfying Java dependancies, quick while you're still enthusiastic And define jar-filename and a a MANIFEST standard for jar's across the ASF; including license references ;-) some level of indirection system where 'jars.apache.org/xerves - maps to a bit of XML with the right info followed by a nice and tight Ant task to do the right thing :-) And should any energy be left over; a niftly class loader (with added crypto checks) would be lovely too :-) I would add: transparent integration with the ASF mirroring system. -- Stefano Mazzocchi [EMAIL PROTECTED]
[FYI] Cocoon Wiki
The Cocoon Project was the first to setup a wiki system. You can find it on http://wiki.cocoondev.org It has been recently 'forrestized' and its effectiveness in creating new useful content has been impressive and over our own expectations. Also, being implemented in Java, it makes it easier for the cocoon community (which is generally perl-agnostic). NOTE: this wiki has been setup more than a month *before* the ASF wiki was in place. But today, 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). 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. I'm telling you this just to let you know. I'm not asking for actions or anything, just pointing out that many different things are happening in wikiland these days (probably influenced by the concept of weblogging? might be) -- Stefano Mazzocchi [EMAIL PROTECTED]
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? 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) 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. Oh, totally. 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. I think Andy has a pretty good point about security, though... see next email. -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: Wiki RSS
Andrew C. Oliver wrote:
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?
eheh, sure. But XML is just a syntax and RSS is just a semantic. If I
have no tool that reads RSS and does something good with it for me, it's
useless data. Well-formed and valid, but still useless.
I emphasize *to me* because I don't run RSS feeds, nor have *any*
intention of doing it since newsfeeds don't go along very well with my
off-line habits (mine and those of million others throughout the world
which aren't as lucky as many here).
Unlike good old asynchronous email.
But I'm not saying that it's a bad idea to have it, gosh no, just that
it is not a general-enough technology for people to use it instead of
email notification.
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.
Oh, great, that removes one of my concerns. Cool.
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.
Don't count on me :(
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.
Ah, good to know.
I am not convinced this is a good idea Might be a great
tool for spamming or exploiting sendmail.
Hmmm, pretty damn good point, didn't think of this one.
Could be wrong...
I'm kinda a paranoid administrator...
Yeah, well, I'm no system administrator and definately not paranoid
these days but I think I know enough about email to question if this is
a real security concern or just paranoia.
I don't think it's possible to write something in a wiki, get it picked
up, sent to a mail list, infect a sendmail of some sort simply by
receiving the message (we use qmail, so no problem from our side, I'm
concerned on the mail list subscriber receiver end) and do something nasty.
If that was possible, then a normal spam flood would do as much damage.
The only thing I see is people abusing the wiki to place shameless plugs
of themselves that get submitted to the mail list.
But email doesn't really change the picture there.
So, call me liberal but I think we have more to loose than to gain in
not allowing diffs forwarding to the mail lists.
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;
}
I don't think I get your point, Andy. What is this different from direct
diff emailing?
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
As I said, I'm not advocating against it, I'm just saying that we need
email nofication also.
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.
I'll let the more sys-adm-savy people take a shot there.
--
Stefano Mazzocchi
Re: Apache Trove
Steven Noels wrote: Hi all, due to the recent and upcoming reorgs in terms of the 'federation'/project/subproject structure and the assumed increased difficulty for people finding their way around ASF projects, I have been playing around with a draft 'trove' application, which isn't much more than some XML XSLT glued together, running on top of Cocoon. http://cocoon.cocoondev.org/mount/trove/ (warning: data entry hasn't been completed yet) This 'app' runs on top of a very free-formed XML document currently: trove federation name=XML keyword name=XML/ site uri=http://xml.apache.org// description[...]/description project name=FOP keyword name=XSL-FO/ keyword name=Java/ site uri=http://xml.apache.org/fop// /project /federation project name=BCEL site uri=http://jakarta.apache.org/bcel// description[...]/description federation name=Jakarta/ keyword name=Java/ /project [...] and should be maintained by the respective project communities. I already went searching what Gump could offer me in terms of available data, but Gump is for obvious reasons limited to Jakarta and XML (Java) projects. Adding the Gump people to add a 'keyword' element to their descriptors wouldn't cause too much harm, but the problem is that I also store the project hierarchy in my data file, and this is slightly orthogonal to Gump's structure. So adding extra data to Gump's descriptors would help, but not enough and not for everybody (including perl/php/...) Another approach might be to store a small trove file per project in the committers cvs module, where assumably everybody has access too, and me aggregating those. The (XML) structure being required would be something like: project name= site uri=/ description/description keyword name=/ (federation name=/) /project Projects can contain projects, and can be grouped into 'federations', aka httpd, xml, jakarta and others. I tried to set up the stylesheets to do something meaningful without many strict requirements on the hierarchy of the datafile. Anyway, this is just a heads-up. I don't know where I could move it too since it falls a bit in-between projects. The presentation is by no means finished, but should be easy to tweak. I can nurture this thing on my own on my own server, but if other people would be interested in playing along, just gimme a yell. Cheers, /Steven I like it!! what about moving the sources over to the community CVS module so that maybe others can play with it and enhance it? Just a random suggestion. -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Sam Ruby wrote: The ASF I wish to be a part of is one and/or create is one that tolerates differences in points of view or approach to solving problems. Amen. -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Justin Erenkrantz wrote: The foundation is responsible for everything on our servers. I don't care for it to be associated with *personal* views. Go find a different soapbox to stand on top of. Your contributions to the ASF don't merit you getting a personal bully pulpit. -- justin There are 450 people with commit access. Each one of them can put something in our servers that can screw the ASF, including web sites. Why is this any different? -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Aaron Bannert wrote: 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. Justin has a very valid point: without proper oversight people might abuse their pages without even knowing they are doing it. Unfortunately, you fail to see that some of us work on so many different projects that it will be a major PITA to scatter our bio information all over the place. It would be *much* easier to link directly to our asf-related personal page. [yeah, let's call it 'ASF personal page' rather than home page so that nobody freaks out] Now, I wonder: why don't we use the 'community' CVS repository for personal pages? (or create another community-pages repository) By doing so we could: 1) have proper oversight because all diffs are sent on a cvs-related mail list like all the other CVS repositories (we could send those diffs here) 2) we are future-compatible in case the apache infrastructure is able to remove the need for account on cvs.apache.org 3) it is easier for non-unix committers to setup their pages since they already have to know how to use CVS. 4) all personal information about everybody is kept in one place, so it's easy for infrastructure people to keep an eye on disk usage for those personally-related information 5) community personal pages don't conflict with existing users pages Possible objections: a) that community cvs module might become huge and I don't want to checkout the whole thing. answer: cvs checkout community/pages/$user/ will download only your stuff. what do you think? -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Ben Hyde wrote: On Sunday, December 1, 2002, at 06:04 AM, Stefano Mazzocchi wrote: Ben Hyde wrote: 'community.apache.org' web site. -1 Uh, thanks Ben. That helped a lot understanding the reasons behind your negative vote. My prior post regarding this enthusiasm follows... Ok, cool. See my comments below. Return-Path: [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Delivered-To: mailing list community@apache.org Received: (qmail 12720 invoked from network); 15 Nov 2002 13:13:49 - Received: from rwcrmhc53.attbi.com (204.127.198.39) by daedalus.apache.org with SMTP; 15 Nov 2002 13:13:49 - Received: from pobox.com (h00055da7108f.ne.client2.attbi.com[66.30.192.113]) by attbi.com (rwcrmhc53) with SMTP id 20021115131348053005tddbe; Fri, 15 Nov 2002 13:13:48 + Date: Fri, 15 Nov 2002 08:14:24 -0500 Subject: Re: @apache web pages Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Ben Hyde [EMAIL PROTECTED] To: community@apache.org Content-Transfer-Encoding: 7bit In-Reply-To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] X-Mailer: Apple Mail (2.546) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. I hear your concerns but today there is no easy way to find out some context about the person that I'm talking to on this list. My personal experience shows that promoting personal context helps creating more friendly communities. The real-life events are a way to promote personal context, but these events will not scale with the amount of people the ASF currently has. Thus a need to find a more decentralized solution. 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. This proposal is exactly about 'puzzling out how to do that productively in cooperative volunteer teams'. The ASF is currently fragmented. Allow me to say balkanized. I see this as a problem. I want to 'puzzle out' how to solve this problem and I think that giving more personal context will help out. This is my personal experience. You might disagree. But try to remember if knowing apache group members in person helped the creation of the httpd community. Sure I'd love to organize gettogethers every week, but we don't have the resources for that. Having homepages for ASF-related stuff might not be as good as meeting people in real life, but it's much better than having just a dry name to confront to. 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. Hope the above explains my intentions. Bringing people closer together is for sure part of 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. I *am* *NOT* proposing to turn apache web pages into weblogs. Weblogs are personal things, I totally and completely agree with you that weblogs should *NOT* be part of those homepages. I just want to be able to associate a name with a person. some bio information, his interests around the ASF and whatever else the person wants me to know about his ASF involvement. my proposal is *NOT*: - about weblogs - about moving all personal info inside the ASF web zone - about forcing people to do anything, but empowering those who want to have their personal info available in a coherent manner The easiest way to avoid a star stage is not to build the stage. Fair, but that is not my intention. Hope my explaination change the picture somehow. -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Sam Ruby wrote: Stefano Mazzocchi wrote: I would like to propose the creation of such a virtual host so that all apache homepages will be hosted at http://community.apache.org/~name That page should be hosted on your public_html directory on your cvs.apache.org account (all committers have one, unlike www.apache.org where only a few do) A very small adjustment to the proposal: make community.apache.org/~name redirect to ~name/public_html/community or some such. This makes it completely opt-in. Those that don't want to participate, are not affected. Good idea. I like it. -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Sander Striker wrote: From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] Sent: 01 December 2002 16:34 Yeah.. I'm confused...what does ANY of the issues brought up have to do with creating the dns entry? It seems some folks are voting/debating the home directories themselves. Those are already there and I assume that decision was already made. I suppose you could propose they be shut down, but I DON'T see what creating the DNS entry has to do with that... But I'm kinda dull, so maybe if someone explains it, I'll get it. Right now the homepages aren't linked to from anywhere and certainly not promoted. Creating the dns entry will seem like promoting the use of the homepages. Yes, that's exactly the intention. people.apache.org or community.apache.org will imply that such a domain entails all the people of the ASF or the entire community of the ASF. It's damn easy to create a list of all committers and provide links only for those who happen to have their ASF homepage available. That solves 'in/out' problems. This simply can never be true since not everyone has time to create and maintain a 'community' area in his homepage area. It's up to you to partecipate in this, but I don't see why the fact that you don't have time should limit others in their ability to be more community friendly. Some of us barely have spare time and are likely to contribute to their projects rather than maintain their 'community' area. Fair, then don't do so. So, in the end, only the people with lots of time on their hands, or simply the most vocal ones, will (likely) be perceived (by visitors of community.apache.org) to _be_ the ASF, instead of a few faces within the ASF. pfff, if I lack the time to partecipate in a mail list discussion should I propose to shut the mail list off until I have enough time? I'm moving my -0 to a -1 on this basis. It would be something else if community.apache.org were only accessible by committers... Sander: since the ASF was created, this page http://www.apache.org/foundation/members.html contains the list of all members and not all of them have the time/will/energy/whatever to maintain an ASF-related homepage (I'm one of them, BTW). Nobody ever said that those linked ones receive more attention than the others. I hope you are not implying this. I agree with you that ASF 'visibility' should not be a function of whether or not you have a homepage setup. So, just like you don't stop discussions if you don't have time, but you still receive messages, I would suggest that we list *all* committers, but then we link only those who do have an ASF-related homepage setup. Does that remove your fears? -- Stefano Mazzocchi [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Sam Ruby wrote: Ben Hyde wrote: //www.apache.org/foundation/members.html I'd be more comfortable if the individual committer pages were hosted outside the apache.org domain, as is the case with this example. - ben With a few notable exceptions, for example: http://www.apache.org/~fielding/ or http://www.apache.org/~stefano/ -- Stefano Mazzocchi [EMAIL PROTECTED]
