Re: Forking is a Feature reactions?
On Sep 13, 2010, at 7:37 AM, Sam Ruby wrote: I just can't resist the opportunity to fork this discussion: http://intertwingly.net/blog/2010/09/13/One-True-Way tee hee have we pushed the apache way pages to git hub yet? - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Project dashboard at eclipse.org
On Nov 11, 2009, at 12:35 PM, Jukka Zitting wrote: Hi, I just found the Eclipse project dashboard at http:// dash.eclipse.org/. They've got pretty nice reports, especially the project activity and diversity charts: http://dash.eclipse.org/dash/commits/web-app/active-projects.cgi http://dash.eclipse.org/dash/commits/web-app/project-diversity.cgi Anyone interested in doing something similar for http://projects.apache.org/? Nope, but I would be very interested in a discussion of how to build dashboards that strengthen community in projects v.s. heighten concerns about it. And! It would be on topic. :) - ben - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: women@a.o mail list
+1 On Jul 28, 2006, at 10:49 AM, Jean T. Anderson wrote: The [EMAIL PROTECTED] mail list was created in August 2005; the initial charter is at http://wiki.apache.org/Women/InitialCharter . We now want to take it to the next step and create a formal committee (see the forwarded post below). Since the women@ list isn't well publicized, I'd like to get the word out that it exists, so feel free to forward this to other Apache lists. Also, we're looking for more volunteers, so if this seems like a fish you'd like to fry [1], you'd be most welcome. regards, -jean [1] http://mail-archives.apache.org/mod_mbox/www-women/200607.mbox/% [EMAIL PROTECTED] Original Message Subject: [PROPOSAL] Move women@ to a project or committee Date: Thu, 27 Jul 2006 20:34:21 -0700 From: Jean T. Anderson [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED],[EMAIL PROTECTED] To: [EMAIL PROTECTED] My post earlier this week [1] was buried in a response to an older thread, so I'm reviving it with its very own subject. This post summarizes the main points and includes feedback from earlier in the week. women@ should become a project or committee (specific structure to be determined). Some reasons include: 1) women@ needs a stable web site with content controlled by committers who are granted karma to a women svn repo. Others, including other Apache committers, are welcome to submit patches, which would be committed after review. 2) The wiki, which already exists, should be a secondary source of information, not the primary. 3) In addition to the public women@ mail list, a private list should be created to ensure that any sensitive issues have a place to be handled. Every project needs volunteers who commit to manage it: - update the web site - review and commit patches submitted by others - respond to questions posted to the list - vote in more committers to the project - provide periodic status reports I had originally thought in terms of women@ moving under the PRC, but discussions earlier in the week suggested that some kind of committee would be a more likely fit. In any event, the Board could determine the best structure after we have assembled enough volunteers to approach them with a proposal. And that's what we need right now: volunteers. So far we have two: - Jean Anderson [1] - Noirin Plunkett [2] Any other volunteers? regards, -jean [1] http://mail-archives.apache.org/mod_mbox/www-women/200607.mbox/% [EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/www-women/200607.mbox/% [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Community at apache.org is publicly archived
Just a reminder. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Organizational analysis of ASF codebases
On Nov 12, 2004, at 10:30 AM, Stefano Mazzocchi wrote: In short, inferring political information ... out of such graphs analysis is purely speculative and should be taken with a little bigger grain of salt. +1 I sat thru a talk the other day were the topology of a PGP key was used to infer political information. It would be silly if it didn't so quickly get turned to a divisive purpose. - ben http://enthusiasm.cozy.org/ -- blog tel:+1-781-240-2221 -- mobile, et.al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open Source, Cold Shoulder (fwd)
On Oct 8, 2004, at 4:55 PM, Brian Behlendorf wrote: Use www.bugmenot.com if you need a password. Comments? Is there anything the community thinks we could do to address the situation? Brian ...http://www.sdmagazine.com/documents/sdm0411b/ yeah, i got comments. The single most toxic thing that you can do to an open source project is to circle the wagons and shun outsiders. Open source projects work by achieving a balance between good people at the core and a horde of talent on the outside. The balance is the key. This article is just a series of cheap shots. Open source is elitist, Open source is hoarding opportunities; in particular from women. Open source is using it's power offensively against outsiders. It wraps that all up by using the analogy of the man/woman dialectic. First: All organizations have a core of people at the center; so you can always accuse any organization of being a clique because they all are. It's a cheap shot. It is much harder to judge if the organization is too much or too little a clique. Anybody with a clue about open source knows that we work very hard on that problem every day. Or to put it another way your not working on that problem you don't have a clue. So the accusation of being too much of a clique is a very serious one. Is the 'open' a lie? Is the absence of women in the statistics a sign of some deep flaw? I doubt it. Why? Because any projects that shuns outsiders is shooting it's self in the foot. Projects that: fail to welcome new comers; fail to bring in credible new contributors ... well they are just stupid. They will ultimately become dysfunctional and implode. That's not to say that it doesn't happen. If you circle the wagons and ignore outsiders then you usually get a short burst of higher productivity; and you get the fun of being all righteous and 3lite. It's just not durable. This is the accusation that open projects are hoarding some opportunities. Well duh! All communities, all institutions, hoard opportunities - for example we hoard commit rights. Healthy open communities strive to hoard the absolute minimum number of opportunities to assure they can stay coordinated and maintain some level of quality. Everything else you struggle to giving away because if you succeed you maximize the level of innovation. Second: The article decides to play with fire. When ever a them/us boundary appears - and they always appear around any community - you can trot out all the old cliches. Old/young, black/white, first-world/third-world, man/woman, rich/poor, big/little - take your pick. In reasonable proportion this kind of reasoning by analogy can be very enlightening. But that isn't the intent of the authors here. They are not attempting to enlighten. They are attempting to polarize. To drag the open source movement into the tar pit of one particular them/us boundary. The culture is full of very highly polarized them/us boundaries rich/poor, man/woman, race, language - just to pick four. It is delusional to pretend that the open source movement wouldn't suffer from a high degree of statistical correlation with all of them. Sometime the alignment is greater, sometime lesser - but it isn't our job to fix those. It's our job to fix the them/us boundary around who owns our particular region of the commons. The right problem for us to worry about is that we need to always strive to bring more people into the loop. For example we do a terrible job of getting visual thinkers into the loop because our entire coordination framework is based around text. For example our anglo-saxon roots has created cultural conventions that make it hard for huge regions of the planet to join the fun. For example we are suffering some serious growth pains that are making the coordination problems much more difficult but meanwhile we are afraid of the power that might accrue to entity we charged with solving those coordination problems. The man/woman dialectic is just not useful as a way of tackling the challenges of how to make an open project grow and remain functional. It's the kind of analogy drives out intelligent thought [as Stefano scratches his ass - indeed]. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open Source, Cold Shoulder (fwd)
On Oct 12, 2004, at 1:21 PM, Niclas Hedhman wrote: On Tuesday 12 October 2004 21:02, Ben Hyde wrote: Projects that: fail to welcome new comers; fail to bring in credible new contributors ... well they are just stupid. They will ultimately become dysfunctional and implode. Question; Should Open Source be Open Participation? I am sure that the upper-tier of ASF would shiver at the thought that hordes of people can gain direct access to the repositories. They/we will dust of the same arguments of why Wiki won't work. But it does. Why? Because *most* people *want* it to work. The question is not a boolean. The question is how does open source manage open participation? The short and therefore meaningless answer is merit. Open source should be open participation, and of course it shouldn't be open to everybody. All organizations have to mange what I call their cell wall, the membrane around them. The membrane is used to manage quality and enable coordinated activity. You can not survive without one. If the membrane is too thick then you stagnate, starve, etc. Here are two things I've written before about his: http://enthusiasm.cozy.org/archives/2004/01/demand-for-features/ and http://enthusiasm.cozy.org/archives/2004/10/hording-and-exploiting/ - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache should join the open source java discussion
On Mar 18, 2004, at 12:18 PM, Geir Magnusson Jr wrote: sheepish I wasn't subscribed to community@ until now, so if there's something there that wasn't xposted to general@, let me know... /sheepish http://nagoya.apache.org/eyebrowse/SummarizeList? [EMAIL PROTECTED] Beware: content is public. The subscription is limited to the committers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF Board Summary for January 21, 2004
Wee! A reply-to header on a posting to committers. Way to go Greg! Your an inspiration to us all! Congratulations to Sander. Much much more so: congratulations to everybody who slaved away on the new license for all these many years. Thank you! - ben On Jan 23, 2004, at 9:14 AM, Greg Stein wrote: Happy New Year! The Board met last Wednesday for its regular, monthly meeting. Since the official board minutes will still need to be drafted, approved, and posted to the web site, I am writing this email to give a brief summary of the actions we took. Since this has an affect on all committers at the ASF, you are receiving this email. In summary: * The Board has approved the new Apache License 2.0. For a copy of that license, please see http://www.apache.org/licenses/. The Board has also mandated that all ASF software must be switched to the new license by March 1st, 2004. Please watch this space for further instructions on how to use the new license. * Last November, Roy Fielding resigned his position as a Director of the ASF in order to have more time to get real work done. Thus, we had a vacancy on the Board which needed to be filled. The Board appointed Sander Striker to fill that seat until the next ASF Members Meeting to be held sometime around June; the Members will elect a new Board at that time. Thanks for all your efforts Roy, and welcome to the Board, Sander! * The Board appointed J. Aaron Farr as the new Chair of the Apache Avalon Project, replacing Berin Loritsch. Berin has been very helpful in getting the Avalon project moving along, but wanted a bit more free time. Aaron is a relative newcomer to the Avalon project, so we hope he can bring some fresh energy to Avalon. Welcome! Please follow up to community@apache.org with any discussion. Also, please feel free to send myself (or any other ASF officer) email if you have comments, questions, or concerns. Cheers, -g -- [EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Location for syndicated Apache blogs
Well it's all well and good until somebody get's hurt. For example Ken's posting about how his Forsythia is blooming and meanwhile it's -1F here and I gather up in NH there are places that are -38F. How do you think that makes me feel? Hot and bothered, that's how! - ben On Jan 9, 2004, at 9:09 AM, Rich Bowen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 9 Jan 2004, Rodent of Unusual Size wrote: Brian Behlendorf wrote: But pulling back, perhaps a way to address Noel's concern is to have this aggregator only pull content from the RSS feeds that the blogger marks as somehow being Apache-related. RSS allows arbitrary metadata, right? Is there an easy way to mark a post in most blogger tools as Apache-related or something? That way someone can rant on and on about their favorite political subject in their blog, but meanwhile only their Apache-related posts get aggregated at the ASF's site. probably not if the rss feed url is scraped from elsewhere. however, if committers can specify particular feed urls, it might be workable -- at least for those people who categorise. for instance, to get the apache-related articles from my log, the feed url i http://Ken.Coar.Org/burrow/index.rss? category=Apachecomments=truewords=all that won't get you the articles about my neverending war with the grey death -- unless they also mention apache somewhere and i marked them as such. i'm pretty sure this is fairly common practice. I tend to think that those things add to the general charm of doing this sort of thing at all. And if I didn't get to read about the grey death, how would I get to laugh until coffee comes out of my nose? Hmm? - -- Rich Bowen - [EMAIL PROTECTED] Did I have the dream, or did the dream have me? (Rush - Nocturne) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE//rYTXP03+sx4yJMRAqALAKDSUISo6VLfdIUvo/rOEClMsFAr0wCaAyMP YWcdxYYzQuw/thCBb3+KqH0= =o7VC -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Location for syndicated Apache blogs
I like the planetapache.org approach. It mimize the coordination costs of getting something up and running. I'd encourage putting any stuff into the committer repository so you can parasite on the infrastructure to allow everybody to pitch in who cares to and just publish the results to the planetapache thang. If it helps, feel free to stick someplace in krell, or not :-). If you don't want to use perl in krell just, that's cool; I think we already have some Java. I'd love to see a 'project' that uses 7-12 different languages ;-) - ben On Jan 8, 2004, at 2:15 PM, Ted Leung wrote: Thom already registered planetapache.org and volunteered to host if. If the ASF changes is mind and wants to host it, I'm sure that could be arranged. On Jan 8, 2004, at 11:11 AM, Sander Temme wrote: Let's just register planetapache.org and be done with it. +1 +1 Would the Foundation handle that, and host it, or would that have to be a private initiative? S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ted Leung Blog: http://www.sauria.com/blog PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Humor] robot.txt
http://www.superbad.com/robots.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache meetup(s)
I'd not noticed this before: http://apache.meetup.com/?change=1localeId=201 I find the idea of encouraging local groups forming around people's interest in various ASF projects to be very cool. That's not intended as an endorsement[1] of meetup.com. It is a very clever idea though, a matchmaker between groups and venues. They charge both sides of the network. If we set up something like it at apache.org it they would have some 'competitive' advantages since we would still have to aggregate venues. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bogus subs to mailing lists (more?)
On Sunday, November 9, 2003, at 12:08 PM, Ben Laurie wrote: Brian Behlendorf wrote: On Fri, 7 Nov 2003, Santiago Gala wrote: Classified for reading until I finish a proposal ;-) A nice scheme against spam, I read about some time ago, was about requiring the email sender to compute a computationally difficult challenge before the email was accepted, for uknown/untrusted senders, something that could take 1 sec CPU time for a reasonable processor. The idea was raising the cost of sending spam and putting it where it belongs. Trusted senders, like the ASF, for instance, would not be required to do it. So, a spammer would have to pay like 1 TeraInstruction per message, and a reasonable PC would send no more than say 3000 spams per hour. This, BTW, would make desirable to send signed messages for bulk senders, since those would be much cheaper to send. Ouch. Daedalus.apache.org sends out over 1M messages per day, and at bursty times 100 per second. How do we convince a non-trivial number of hosts to trust us and not require that computation? You require hash-cash for list postings and sign them for redistribution. Such a signature would, i hope, assert little. Is a spec for signing the headers added to forwarded mail? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RfP: Apache T-Shirt Logo Contest
I wonder how subtle and detailed the printers can be? Black shirt, a small pair of white dice, over the heart, the spots upon which are feathers. Then there is the ever popular enumeration in extremely fine print of the set of committers; I've always wanted to do one of those with the substituted into the text of a product's source code. On Wednesday, October 29, 2003, at 05:06 PM, Gregor J. Rothfuss wrote: Hi community, here's another submission: http://www.cocooncenter.org/apache/apache-bandit-02.png Greetings -- Andreas +1 -- Gregor J. Rothfuss Wyona Inc. - Open Source Content Management - Apache Lenya http://wyona.com http://cocoon.apache.org/lenya [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Book about The Apache Software Foundation
Clearly this mailing list needs a little levity today. Without futher ado I forward this lame solicitation... As one of my correspondents commented Clear Mr. Miller is not a native human-speaker, in fact he fails the Turning test Begin forwarded message: From: Stewart Miller [EMAIL PROTECTED] Date: Sun Oct 19, 2003 4:15:26 PM US/Eastern To: [EMAIL PROTECTED] Subject: Book about The Apache Software Foundation Ben, It is my intent and desire to work with The Apache Software Foundation such that a person in your position as VP, Apache HTTP Server Project may hopefully benefit from my expertise in the Networking Connectivity Software field. It would be most advantageous for me to work directly with The Apache Software Foundation to create a book that I can publish about Networking Connectivity Software detailing how customers and business partners can use your product's technical features and functionality. My goal is to empower you with a special book that will serve to build revenue. My consulting career is deeply rooted in Fortune 500 companies including IBM, Ernst Young, SAP, and Microsoft. I have written for and been quoted extensively in several global technology news and magazines both in print and online media. The 11 high-profile books I've published have significantly increased revenue and greatly promoted product sales for each company I've written about. I feel I can provide something very unique and special to The Apache Software Foundation by writing this kind of book for you. Please verify my success in this area by checking my published work on Amazon.com to see how I've promoted revenue for companies including SAP, PeopleSoft, and IBM. I helped my clients increase thier sales revenue by publishing this unique kind of book, so I know I can most assuredly help you too! Please give me a chance to speak with you, and I shall endeavor to prove my worth to The Apache Software Foundation in this capacity. Ben, please arrange a time for us to speak on the phone at your earliest possible convenience to discuss this position in further detail, as I am most interested in working on this project with The Apache Software Foundation and contributing something very special to our mutually beneficial future. Respectfully, Stewart Miller Director, Executive Information Services Pager/VoiceMail# 1-800-IT-Maven Stewart Miller's Resume: http://www.ITMaven.NET/ E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get pgp keys signed
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... 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to get pgp keys signed
I assume that people more knowledgeable than I will critique this, but this works for me... A conference provides a great opportunity to get your pgp key signed and to sign a the keys of others, but it is just somewhat easier to assert somebody's identity in person. A little prep can make all the difference. Before you go you should 1) know how to find a key (at the MIT key server for example http://pgp.mit.edu/ ), 2) you should have a passing familiarity with the software for manipulating keys (GPG probably), 3) you should have a key, 4) you should have printed up a few dozen scraps of paper with your key's fingerprint on it. 5) you should be prepared to capture the fingerprint of other folks (who didn't come prepared with a scrap of paper) so you can sign their keys. Step #4 is the important one. That scrap of paper might look like this: pub 1024R/187BD68D 1997-09-30 Ben Hyde [EMAIL PROTECTED] Key fingerprint = 90 AA 4C 16 6C 9D 12 DC 3D 8B 86 E5 0E 33 CE 52 When you encounter folks who might sign your key offer them the scrap of paper with your finger print on it and ask for one in return. Always ask to see some official (picture, goverment, etc) ID. You might be tempted to ask for official ID only when your less than absolutely certain that you know who your dealing with. By always asking you both set a good precedent and you don't have to be admit when you are or entirely aren't certain about somebody's identity. That can be embarrassing. Later, but soon, you should: (a) find their key, (b) sign it and (c) upload the result back to the key server you down loaded it from in step (a). Your done, your cool. With luck they will get around to signing your key at some point too. Signing a key does not indicate that you trust the person. It only indicates that you believe that key is associated with the correct person. In fact it's valuable to the whole network of signatures if you sign the keys of members of other communities. So signing the keys of near strangers is a good thing. Just be confident of their identity. Tricks for slightly improving the efficiency of this: Since step #4 of the prep work is the important one you can get some mass production efficiencies. I) Print the fingerprints of people you expect to encounter: It's a pain writing down a fingerprint by hand. You can avoid that by printing up a sheet of paper with everybody you hope to meet's finger print on it. When you meet them you can then check that they agree that's their fingerprint. You then make a mark on your paper and do your signing later. II) Make a handout with the fingerprints of attendees printed up on it: Sometimes people will hand out a paper like that. Do not sign all the keys on that paper. You must assert each identity one at a time. You don't need a conference to do this. I carry a few of the #4 scraps of paper in my wallet, but I never remember to hand them to people when I meet them. Some people are so cool they have the finger print printed on their business card; or stored in their PDA where they can beam it to folks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get pgp keys signed
This is now found here: committers: docs/pgp-key-signing.txt So that editors and pgp mavens can push it up hill. - ben On Monday, October 13, 2003, at 10:52 AM, Ben Hyde wrote: A conference provides a great opportunity to get your pgp key signed and to sign a the keys of others, but it is just somewhat easier to assert somebody's identity in person. A little prep can make all the difference. Before you go you should 1) know how to find a key (at the MIT key server for example http://pgp.mit.edu/ ), 2) you should have a passing familiarity with the software for manipulating keys (GPG probably), 3) you should have a key, 4) you should have printed up a few dozen scraps of paper with your key's fingerprint on it. 5) you should ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: annou...@apache.org, was Re: Newsletter.
Ah! It sounds as if other people aren't aware of the background and original intent. From what you are saying, announce@apache.org should be subscribed to announce@tlp.apache.org. That way announcements would automatically funnel to [EMAIL PROTECTED] Is that right? I'm not suggesting we reopen any discussion, I just want to be sure that is in fact what was agreed last time around :-). So: announce@apache.org being the sum of traffic list on all announce lists? - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newsletter.
Soliciting amusing war stories from the larger community would be fun. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WORA Considered Evil ;-)
On Wednesday, July 2, 2003, at 10:46 AM, Serge Knystautas wrote: Santiago Gala wrote: I think a good equilibrium point between the marketing view of security (making sysadms trust) and purist java technical view would be to allow James not having to run as root under Unix (to handle protected ports like 25, 110, etc.) and then securing the rest of the processing through java security declarations. Since people here know qmail and sendmail a lot better than I do... how do they bind to those ports without running as root? A guiding principal of qmail is no process should do more than the absolute minimum and it certainly shouldn't have any more rights than the absolute minimum. Living up to those principals demands having lots of user accounts, each with exactly the minimum number of rights, and then using fork to create safe bubbles - you setting the user before forking to create the bubbles, and then cleverly passing just the right stuff to these processes to give them the right capabilities. So for example a process that's root has the right to create a listener, but that process can then fork a process passing it that listener to give the capability to process/user with much more restricted rights. We used to have a patch for HTTP that allowed a short lived root process to create the HTTP listener and then pass that open file handle to the server (notifying it were to find it via a parameter). That enabled the entire server to run in user space. It fell off the wagon at some point. I know nothing about sendmail, makes you jealous doesn't it? - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Concept Maps
,... the Concept Map idea I listened to a talk by a guy who's obviously spent most of his life hacking this thing; http://www.compendiuminstitute.org/tools/d3einterface.htm He seemed quite clueful. It was mostly built at ATT, then Verizon. He has been trying an open source move over the last few years; with mixed success. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The cash of our lives / Dvorak
On Tuesday, June 10, 2003, at 03:01 PM, Greg Stein wrote: On Tue, Jun 10, 2003 at 01:58:16PM +0100, Danny Angus wrote: Jeff, Yes, and isn't it fun. --fun snipped-- ;-) So should we only do things that are fun? Moving and re-naming files in an ssh terminal session is not crazily graphical nor easy enough for a 4 year old, but I bet there are enough people in Apache who can do it without sweating that it is, IMO, a poor excuse for throwing away useful information. Bah. ObPlug Use Subversion. /ObPlug :-) -- Greg Stein, http://www.lyra.org/ Nope that didn't seem to help - ben $ telnet svn.apache.org 80 Trying 208.185.179.13... Connected to svn.apache.org. Escape character is '^]'. dir c: dir c: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title400 Bad Request/title /headbody h1Bad Request/h1 pYour browser sent a request that this server could not understand.br / /p hr / addressApache/2.1.0-dev (Unix) SVN/0.23.0+ DAV/2 Server at icarus.apache.org Port 80/address /body/html Connection closed by foreign host. $ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: that map
Danny Angus wrote: I've just got round to adding myself to the map (http://cvs.apache.org/~sgala/map.html), late as usual. Well done everyone involved, I love it. Everyone else.. get yourselves on the map so I can see where you live. Instructions: cvs -d cvs.apache.org:/home/cvs checkout committers $EDITOR committers/krell/FAQ - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: that map
Doesn't work in emacs via w3 either! - ben On Tuesday, April 8, 2003, at 09:11 AM, Danny Angus wrote: It would be great to have a javascript wizard working on the UI, at least on mozilla it is a bit fragile. Oh yes, it doesn't work for me, better break out MSIE (cough cough!). d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: news.apache.org (was: apache.org vs. mozilla.org)
A note were in Ben has post Vietnam flashback... Justin Erenkrantz wrote: Leo Simons [EMAIL PROTECTED] wrote: NNTP makes more sense than SMTP for group discussions. No, it doesn't necessarily. I was in a room yesterday with a lot of people who have been spending way too much time attempting to 'understand open source'. I am always greatly amused by these gathering because you have a group of extremely smart people attempting to tease apart the mystery of what we do. That's fascinating to listen too. But they are always attempting to do so with out getting the hands dirty. At one point during the day they spent a good two hours discussing one thread in the Linux kernel mailing list. They looked at the first four messages and then were given a summary of the other 175 messages. I was the only person in the room that had the least clue what the topic of the thread was. What I often say in these gathering is that Open Source is both a very old process, i.e. people cooperating to solve problems, and a very new one, i.e. manufacturing of a document intermediated by computers. We are a long way from having searched the space of all possible schemes for doing it effectively. That even the simplest things, like what affordances on the tools might help are just beginning to get some experimentation. For example would open source projects work better if CVS was more enthusiastic about forking? Would a cooperative drawing tools help? Is there a right size for a repository, or a community, or an appropriate way to manage the boundaries around these? Nobody knows, but we have lots of intuitions that may or may not just be cargo cult experiences. I have a lot of nostalgic affection for using NNTP rather than SMTP for this stuff. The first project I ever worked on that was effectively intermediated using computers and networks used NNTP. 1980-85 I worked on a very complex compiler project and we used NNTP to organize the narrative around the work. For example we used individual threads for each bug. We never discarded any messages. The entire message store was in flat files on the file system so we could use unix tools to search for lost bits of info - like did heather say something about stack chunks a few weeks back. I vividly recall noticing about half way thru that project that we all stopped talking about the work in the halls, that we only talked about life in the halls. That struck some of the management as very odd. We had stumbled on the discovery that by normalizing the work so it all happened in one place intermediated by the machine we were more thoughtful, more efficient, more convivial, effective due to the orthogonal skills, able to tap into bits of serendipity, able to work with people who could be prickly in person, etc. etc. etc. This was also the first time I saw automated builds and testing used to help developers avoid embarrassment. The first time I saw builds and testing triggered by commits so we could shorten the interval between break and fix - and hence increase the chance that the guy that broke it could remember what he thought he was doing. It was also the first time I got the commits posted to netnews so many eyes could casually proof read them. One thing that would happen in that context was that NNTP threads would often lie idle for months only to suddenly come back to life. That is one reason it could be used for working on individual bugs/enhancements/ports/etc. The threading seemed more robust then it it ever seems to in [EMAIL PROTECTED] I assume that was because we were all using the exact same client software then. These days I have a lot of trouble seeing the difference between a good news setup and a good mail setup. But both need archive, threading, search etc. etc. I run all the dev@apr.apache.org email into my in-house news server, for example. Of course the major user list for httpd is netnews based. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [off-topic-just for fun] - Maps and zoom-in
Santiago Gala wrote: Another one, ~n in ~nacho gives a newline in krell/bin/scrape_location.pl, and thus fails. I don't speak enough perl for this one. My fault. I've poked a repair into the sources. (Funny, it took 57 people to trigger these bug, while n should be 1/25 or so ;-) We can learn that: With enough data, all software is buggy ;-) I like that Given enough eyes all bugs are shallow. is four metaphors in one sentence (thanks to Karen Healy[1] for noticing three of them). - ben [1] http://www.kieranhealy.org/blog/ -- her blog. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to place Agora?
On Wednesday, February 5, 2003, at 11:40 AM, Stefano Mazzocchi wrote: 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? I prefer never to create any files in the root directory. In any-case we already have the committers repos, and if we decide to create another one then we really ought to have a discussion about which PMC is responsible for cleaning up any farts it leaves in the air. If we stay in the privacy of the committers repository we can avoid all that and get back to the fun of emerging somethings. There isn't a community module is there? - That's a sentence that I certainly enjoyed writing. -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine neccesitate [William of Ockham] I think unity is a mistake If I were the Establishment and had the big loaded guns of the various oppressive institutions I would much prefer to see one lion come through the door than 500 mice. - Florynce R. Kennedy and in a wonderful example of google performing in the role of smart ass: Did you mean: Pluralitas non est ponenda sine _necessitate_ :-) They must be too proud that they can do spelling correction on latin, ekk. They scare me. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to place Agora?
Agora and krell are both about navel gazing. My father and a colleague once designed a complex optical instrument that allowed it's user to gaze at his navel without lifting his head from the pillow. These are interesting boondoggles. I like that they both consist of little more than scrapping some data and then displaying them with tool that gives a nice view. Almost the definition of fun - low energy in, high energy out. I was explaining to my son how whenever you map something, or collect statistics on something and display them observers rush to conclusions about them. Oh look, he certainly is an outlier. or Humm, quite a crowd over there!He seems wise for his age: The dangers of data. Nice quote from a recent article in the Boston Globe: While most of your embarrassing baggage was already available to the public, it was effectively off-limits to everyone but the professionally intrepid or supremely nosy. ... It's the collapse of inconvenience, says Siva Vaidhyanathan, assistant professor of culture and communication at New York University. It turns out inconvenience was a really important part of our lives, and we didn't realize it. I agree that data emergence is a better model than front loading things like this with a knowledge management design process. So in sum I find the navel gazing an interesting way to bring some smart people with unique skills to work on these problems of privacy, emergence, and community analysis. An interesting design space - but _yeah!_ data is dangerous. 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 :-). - ben ps. In case your not already aware the ivory tower dudes are having a field day with all the data in our logs. For example this data about power law distributions in the logs. http://fiachra.soc.arizona.edu/blog/archives/000257.html#000257 or more generally: http://opensource.mit.edu/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where we are.. continued..
If I hadn't moved the SIM in my phone into another phone they don't support I could try this. http://www.askbjoernhansen.com/archives/2002/09/12/000145.html Presumably built on the E911 requirement. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How get on the map!
a hi-rez version of that background map http://visibleearth.nasa.gov/cgi-bin/viewrecord?11656 http://www.radcyberzine.com/xglobe/ http://awka.sourceforge.net/xglobe.html My favorite? http://flatplanet.sourceforge.net/maps/images/1678k5.jpg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How get on the map!
Dirk-Willem, Santiago - too cool! Thanks to all for fixing my typos and adding more doco! I can't make maps at until I convince one of the machines in my house to build a version of xworld with tiff and gif||png support. 39 people in committers/urls.txt, but that's a small subset the 600+ in /etc/passwd. From an architectural point some things I'm thinking about. 1. The data gathering should be separate from the report/map generation. 2. Privacy policy statements are badly needed, particularly when you want to display more interesting data, like time of last commit. This is, darn it, an interesting design problem. 3. I very much don't want the data or the reports checked into CVS. 4. It would be fun to pull RSS alternate links as well and use that to highlight those people with recent postings. 5. It would be very interesting to look into signing, encrypting, etc the contents of the page. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How get on the map!
I've moved the map here: http://cvs.apache.org/~bhyde/map.jpg Too many enhancements in one day... - ben On Friday, January 31, 2003, at 05:31 PM, Ben Hyde wrote: The map is looking better. http://www.cozy.org/ben/map.jpg 21 locations known plus 4 more in urls.jpg who are keeping their location a secret. I guessed where they are and put them Antarctica. Here's how to join the fun: 1. Check out the committer's repository: cvs -d cvs.apache.org:/home/cvs co committers 2. Read the FAQ: committers/krell/FAQ - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we have a problem :)
Costin Manolache wrote: My point was: if someone posts a mail with pointers to warez or porn or spam - it will get through and will be archived in the mailing list archives. Humm, are we arguing with the stop sign here? We seem close to a settling in on that rare and wonderful thing - a consensus about what to do. Is this hair splitting moving us toward that delightful goal? Maybe I'm missing the scale of the point your making. I'll admit I find it an interesting analogy, so I'll take the bait ... but first ... My sense is that people are reasonably comfortable with attempting to move toward a model where there are N wiki are owned and operated by individual PMCs. Those PMC can then strive to make those 'documents' reflect their sense of what makes them proud. Meanwhile interlinking and good search tools should make this just as delightful as the current ownerless wiki. I see a few good things about that. It resolves a problem for the board, i.e. that it's their legal responsibility requires that they have a simple awnser to the who's in charge question. It creates pools of light were pride of ownership can illuminate the work of polishing the content. It lets us get some diversity of approaches. It makes me happy since it's an idea I've been advocating - and really that's all that's important. Right now I think the Wiki is really neat, but I'm not proud of it. I don't feel enough ownership to fight the good fight to fix that; but I am willing to advocate a restructuring that would create - ah - smaller oceans to boil. To get at your point. I find it interesting because it seems to get to the heart of how the open source process tried to create a engine that sums up the skills and reputations of individuals into results that are better than the parts, results that have higher reputations than the individuals could probably create on their own. I do see a striking difference between the wiki and the mailing list. The mailing list is the transcript of a conversation among assorted parties. If I post a stupid, rude, lame, illegal, embarrassing thing to the mailing list there is little doubt that it was me who takes the responsibility for that. It is my reputation that suffers. The reputation of the list, and in turn the PMC that owns and manages that list suffers only by association. In a list with enough contributors that association will be limited. The Wiki, on the other hand, give the impression of being the document of the organization (or I hope a PMC). The readers and the writers of that document are encouraged to treat it in that way. So if I go in and write something stupid, rude, lame, illegal, embarrassing in the Wiki the first impression of the reader is not who ever wrote this is a twit it's that this document's authors are twits. The association seems much stronger. You could argue the same thing is true in a mailing list. If I enter a mailing list and the first few posting are twit-rich(tm) I am as likely to think The people on this list are twits. as the more accurate Those three are being twits today. It's interesting to consider the very nice example of PHP's easy to edit manual annotations. When you read those pages you get a very clear dividing line between the content that is reflects upon the reputation of the PHP doc team and the vs. the content that reflects upon random individuals. As a user of that manual I know to take the comments with a grain (often a very large grain) of salt. Of course this whole business about how to design systems that have low barriers to entry but then filter out the really good stuff is at the heart of open source, source forge, everything2, etc. etc. Lots of room for experimentation. Presumably when people dis source forge they are critical of the balance they have struck between barrier to entry and filtering. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How get on the map!
Santiago Gala wrote: I'm thinking that the best way to show the names, ... Apparently the radius label doesn't work in marker files for my version of xplanet. I'm sure I saw examples of labels floating in space over the markers on the globe. Meanwhile I'm musing about some kind of policy statements that would allow people to clarify their permissiong of such privacy invading activities... Dirk-Willem van Gulik wrote: Ben - could you also put the harversted lat/lon list there ? Prefered: cvs co committers cd committers/krell make tmp/geomarkers Currently: http://cvs.apache.org/markers.txt For that you only need unix and perl. I'd like to slap a WMS (Open GIS Web Mapping Server) interface over it - so one can doe things like zoom in; or change the background, add roads, etc. Oh that would be neat! David Crossley wrote: Wow, great work Ben and Santiago. I added to the FAQ to explain geographic co-ordinates. Some people have their latitude and longitude reversed. Thanks! The obvious ones are: bdelacretaz, gstein, jwoolley Actually they haven't exposed their location, so I dumped then in Antarctica. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we have a problem :)
On Saturday, February 1, 2003, at 02:10 PM, Noel J. Bergman wrote:
a solution using the current Wiki code, I imagine that it would look
something like:
http://james.apache.org/wiki/
http://jakarta.apache.org/wiki/
http://avalon.apache.org/wiki/
http://xml.apache.org/wiki
http://incubator.apache.org/wiki
I'll note that the entire behavior of the wiki.pl script hangs by the
thread
of this line:
$DataDir = ...;
If you modify that so it looks up the data dir based on the
$ENV{DOCUMENT_ROOT} or some other environment variable then the
provisioning of another PMC's wiki can pretty minimal.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we've got a proposed solution - hierarchy
My understanding ... The current Wiki, not being under any PMC oversight, would go away. I hope we don't tear down the current one for a bit, make sure the PMC owned ones are a functional replacement. Put some markings on the current one. Move content, leave interlinks. Try to nudge people over to those, etc. I'd be reluctant to rush to garbage collect. If one's lucky then no toes need get stepped on, just a transition to - what appears to me to be - a better model. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we have a problem :)
Interesting conversation. http://everything2.com/ is another interesting example in this space. They keep all the content associated with an author. They have a surprisingly complex scheme for getting a feedback loop that they hope will create quality. One thing that fascinated me about was that they users of that system seemed a little unclear what 'quality' they were trying to create. After a while the quality being maximized that seemed to emerge was 'cool'. I had a fun discussion with somebody from that group about how it might be entirely different if people rated the content using icons. I might say that one entry has very smilie-face while another bit of content was very tree, bicycle, cloud, etc. That it would have created multiple quality vectors that the system could hill climb over. In any case that system is kind of 80% wiki plus 20% slashdot with a mess of learning from the slashdot experience thrown in for free. Sorry for not really replying to your note. It's a big fuzzy topic... - ben On Saturday, February 1, 2003, at 02:50 AM, Costin Manolache wrote: On Fri, 31 Jan 2003, Ben Hyde wrote: Costin Manolache wrote: My point was: if someone posts a mail with pointers to warez or porn or spam - it will get through and will be archived in the mailing list archives. Humm, are we arguing with the stop sign here? We seem close to a settling in on that rare and wonderful thing - a consensus about what to do. Is this hair splitting moving us toward that delightful goal? I'm sorry for not beeing clearer - I fully agree with most of what you say, and I think making the wiki more structured is good for many reasons. There is no doubt that having oversight - people keeping the wiki under control - is good. My concerns is over where do we draw the line - after the oversight is in place. The extremes are clear - porn will be removed, and excelent documentation will be included in the products and their authors may become committers. What happens in between is a different story. My opinion is that wiki should be treated as mailing lists - and not as source code in CVS and subject to consensus. The real problem is not the warez or porn - that's something we'll know how to handle. What if someone creates a page ApacheFooSucks ( where Foo is one of the apache projects ) ? And it includes a list of problems and arguments - just like he would do it in the mailing list. Are we going to remove it - or just create ApacheFooIsGreat with counter-arguments ? What if it's about JCP ? Or GPL ? Or the best web development technology ? Do we keep or remove those pages ? Maybe I'm missing the scale of the point your making. I'll admit I find it an interesting analogy, so I'll take the bait ... but first ... I think the problem is a bit larger than warez and the need to monitor wiki. Chosing where to draw the line between free opinions ( as in mailing lists ) and full consensus ( as in code committs ) is a bit harder than sending notifications to the mailing lists ( where we seem to have a pretty broad agreement ). The really important argument you make is: I do see a striking difference between the wiki and the mailing list. The mailing list is the transcript of a conversation among assorted parties. I do see wiki as a transcript of opinions and ideas of a user. It's better than the mailing list because it has structure and link and doesn't get lost. But it's fundamentally the same - an unbound number of people posting their toughts. If we treat the wiki as: The Wiki, on the other hand, give the impression of being the document of the organization (or I hope a PMC). The readers and the writers of then we are bound to be disapointed and we'll misuse wiki. IMHO what's important is to find a way to make it clear and agree that wiki is not the oficial document of apache, just like the opinions of apache members posted on mailing lists are not the apache oficial position. ( sorry for cutting parts of your reply ) Costin that document are encouraged to treat it in that way. So if I go in and write something stupid, rude, lame, illegal, embarrassing in the Wiki the first impression of the reader is not who ever wrote this is a twit it's that this document's authors are twits. The association seems much stronger. You could argue the same thing is true in a mailing list. If I enter a mailing list and the first few posting are twit-rich(tm) I am as likely to think The people on this list are twits. as the more accurate Those three are being twits today. It's interesting to consider the very nice example of PHP's easy to edit manual annotations. When you read those pages you get a very clear dividing line between the content that is reflects upon the reputation of the PHP doc team and the vs. the content that reflects upon random individuals. As a user of that manual I know to take the comments with a grain (often a very large grain) of salt. Of course this whole business about how
Re: Wiki - we've got a proposed solution - hierarchy
Noel J. Bergman wrote: I hope we don't tear down the current one for a bit, make sure the PMC owned ones are a functional replacement. I understand your concern about data loss, and share it. See my comment about starting the new ones as clones of the current one. And no need to take down the old one (maybe make it read-only because of oversight concerns?) until the PMCs say that they're done. Thinking about it some more. I guess my concern is less about the data and more about the people. I'm most concerned about pulling the rug out from under people having fun before their a place they can move their fun to. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
On Friday, January 31, 2003, at 12:48 PM, Santiago Gala wrote: Rodent of Unusual Size wrote: Ben Hyde wrote: http://www.cozy.org/ben/map.jpg heh. lookit all the developers in the middle of the pacific. :-) I'm currently dumping people who's pages lack a location meta tag into the Pacific, but I'm considering sprinkling them over the Antarctic instead. When I ran it on cvs this (european) morning it was even worse: crosley lived on the edge. :-) I had a patch fot this, then I got a conflict. Still, I think :-) Apparently we were both trying to rescue Mr. Crosley from getting torn apart at the same time. Index: Makefile === RCS file: /home/cvs/committers/krell/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- Makefile 31 Jan 2003 13:28:02 - 1.3 +++ Makefile 31 Jan 2003 17:46:59 - @@ -22,7 +22,7 @@ # -longitude -30 -color yellow # All day SKIN=-geometry 800x400 -night_image earth.jpg -projection rectangular \ - -longitude -0 -color red + -longitude 10 -color red all : $(MAP) $(PRIVATEMAP) Is better, since it minimises risk of land being on the edge :-) yes better, committed. - thanks - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
Sander Striker wrote: From: David N. Welton [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 10:49 PM Ceki G|lc| [EMAIL PROTECTED] writes: What do URLs have to do with Intercontinental Ballistic Missiles? Does not compute. Really... who wants to parse up some file, and have a spider visit a bunch of sites just to get the same information that could have been put in a file on cvs.apache.org or directly in the committers repository. +1. As someone who doesn't maintain a personal site and doesn't want to just to put ICBM info there, I'd prefer to just put my info in a file directly. Fair. Good news, you don't need to have a personal site, all you need is a place to put a page you control. Happy day there is your ~/public_html/foobar.html on cvs.apache.org, e.g. http://cvs.apache.org/~bhyde/ Then I'll admit I had assorted hidden agendas. I'm very interested the theory and practice of an identity system that avoids having _any_ hub what so ever. I'm sad to have the url.txt file at all. I'd rather have done some of those cool new uri/dns tricks. I'm curious if it's actually viable for identity info to be maintained closer to the entity identified rather than the identity provider. I believe that such info should be volunteered rather than ascribed. I'm very interested in the problem of how you aggregate knowledge about entities in any identity system with out prejudging what that info might be. So I tried to pick the least-est info to accumulate it first and I wanted it distributed immediately so that it would force the enterprise to never assume it had control very much over the actual data. I think for a hack like this to scale well and grow fast you need to have it spitting fun value out at every step along the way. It's more fun for me to scrap than design XML schemas. I think it's healthy if the schema designers are trying to catch up with the genie after it gets out of the bottle. I wanted to have some fun in this list, but fast. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
This will scrap the locations...
#!/usr/bin/perl
use LWP::UserAgent;
my $ua = LWP::UserAgent-new(timeout=30, agent=Krell-GeoScraper/0.1
);
# $ua-agent();
open(F, urls.txt);
while(F){
chop;
my ($username, $url) = split(/: */, $_, 2);
my $res = $ua-request(HTTP::Request-new(GET = $url));
my ($lat, $lon)
= $res-content
=~
m{meta\s+name\s*=\s*ICBM\s+content=(\s*[.+0-9-]*)\s*[,;]\s*([.+0-9-
]*)\s*\s*[/]*}is
if $res-is_success;
print $username:$lat:$lon:$url\n;
}
close(F);
... i.e.
bhyde:42.41528:-71.15694:http://enthusiasm.cozy.org/
erikabele:48.7942:10.1151:http://www.codefaktor.de/weblog/
coar:35.90528:-78.85000:http://Ken.Coar.Org/blog/
fitz:-87.67350:41.97200:http://www.red-bean.com/fitz/
jwoolley:::http://www.cs.virginia.edu/~jcw5q/
stevenn:51.0749:3.7473:http://blogs.cocoondev.org/stevenn/
thommay:51.502798:-0.329835:http://www.planetarytramp.net/
- ben
ps. I kind of feel somewhat that the user names are private and ought
not appear in any public reports; humm...
pps. you gotta love regular expression, well you do if your ever going
to understand da bastards.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
On Thursday, January 30, 2003, at 06:20 AM, Rich Bowen wrote: Where's a good place to get (correct) coordinates? I got mine off the topo-map in the basement stairway, come on over. Failing that: http://www.topozone.com/ -- you have to tinker to get lat/long http://mapquest.com/ -- preferred by the guys at http://www.geocaching.com/ Then there is borrowing a GPS. Meanwhile this map: http://www.fsfeurope.org/coposys/maps/fsf-800x400.png claimed to come from this software: http://savannah.nongnu.org/projects/coposys/ That in turn appears to be based on xplanet http://xplanet.sourceforge.net/ or at least it's ./configure ... - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
http://www.cozy.org/ben/map.jpg cvs up committers cd committers/krell make ... creates map.jpg assuming you have xplanet A mac os x installer package for xplanet is available here: http://macosx.forked.net/showcat.php?cat=Miscellaneoussortmethod=name - put's it in /usr/local/bin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open community (was ... secret discussions ...)
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
Re: [poll] weblog package on apache.org ?
Henri Gomez wrote: Questions : - Did there is a need for a weblog package installed at apache.org where commiters could put notes about THEIR ASF related works ? I have no problem with PMCs having weblogs as part of their public face. I am concerned that this diverts attention from the code and the cooperative work on that code. I prefer that oversight of this remain encapsulated with the PMC and that individual PMC make the decision if they have the bandwidth to do that oversight. I liked like to see some experimentation with PMC blogs where for example all of some selected kind are allowed to post. I think that would be interesting to see how it works. I'm concerned that if the 'selected kind' was a dozen people only one or two would post and that would give the impression that those one or two had a unique voice in that PMC. That said I think it could be an interesting experiment. I think it's premature for big leap of faith that blogs.apache.org or some similar would make things function more smoothly. - Should we select a Java based solution (the request came from jakarta-general initially), or anything else ? Another good example of why this might be best left to the PMCs. - Which packages/products are good candidates, having licence without apache members/commiters contestations ? I'd very much prefer something with a compatible license. Something I we can all provide patches for. - ben - 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. Sorry if that seemed directed at anyone in particular. It was intended it more as a plea to the collective hive-mind to attempt to heal rather than claw at old wounds that are now presumably healing. Sort of a hope we could move on to next thing. - ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where are we?
I wonder if we could do something fun. I think it would be fun to have a map that shows where the various people in the community are located on the planet. My fuzzy idea is that members of the community would put ICBM tags[1] on some web page of their. That can drive the map building. Use the author tag to grab their names. They then put some other kind of tag on a page, like meta name=ASF-KIND content=committer They then poke something we keep back at central command so we can accumulate the list. If we use committers repository for that we can easily authenticate people. If we keep it simple to start we can obviously do assorted richer things later, but if all we try to do up front is get a map of the committers that would be sufficiently neat. wdyt? - ben [1] http://geourl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
Actually we could skip the ASF-KIND boondoggle at first too. At that point the only thing we need is to collect URL's that have the icbm info in them. This will make so much easier for the authorities when the time comes! - ben On Wednesday, January 29, 2003, at 02:03 PM, Martin van den Bemt wrote: Cool +1.. I've already setup geoUrl so the headers are in place. (except for the ASF-KIND though) Mvgr, Martin -Original Message- From: Ben Hyde [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 19:58 To: community@apache.org Subject: Where are we? I wonder if we could do something fun. I think it would be fun to have a map that shows where the various people in the community are located on the planet. My fuzzy idea is that members of the community would put ICBM tags[1] on some web page of their. That can drive the map building. Use the author tag to grab their names. They then put some other kind of tag on a page, like meta name=ASF-KIND content=committer They then poke something we keep back at central command so we can accumulate the list. If we use committers repository for that we can easily authenticate people. If we keep it simple to start we can obviously do assorted richer things later, but if all we try to do up front is get a map of the committers that would be sufficiently neat. wdyt? - ben [1] http://geourl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
[1] http://geourl.com/ ekk! I meant:http://geourl.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
Never right specs in a fright container. On Wednesday, January 29, 2003, at 02:36 PM, Martin van den Bemt wrote: Just heard a plain is perfect for spec writing :) (Dirk-Willem?) The result is called PLOP (for belgians and dutch people with kids : Nee geen Kabouter Plop!) See http://www-nrc.nokia.com/mail-archive/ietf-spatial/msg00358.html for details :) Mvgr, Martin -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 20:25 To: community@apache.org Subject: Re: Where are we? --On Wednesday, January 29, 2003 19:15:16 + David Reid [EMAIL PROTECTED] wrote: Do we have to be truthful and honest? :) Maybe we could have one that shows where we'd *like* to be... In your case, we could show where your plane is. 40,000ft above the Atlantic Ocean in the middle of nowhere. =) -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we?
Steven Noels wrote: That's about as low on the food chain as we can go 'knowledge representation' wise. Should we climb higher, and if so ... why? nope, KISS Lies! Ok so the file is in /etc/passwd style with three columns separated by colons. The first field is your cvs.apache.org login id, the second and third combine to make a URL. The first column is the key and should be unique over the file. Anybody know how to make a map? not yet - but it is fun thing to ponder with :) Humm: http://p2pmap.org/tarballs/gserver/exe/gserver.html ...: http://p2pmap.org/blog.html see the Jan. 15. 03 entry. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Administration
Noel J. Bergman wrote: Ben Hyde wrote: Noel J. Bergman wrote: Andy gave ... and Ben Hyde admin access. Wires got crossed someplace and that didn't come to closure. It's been a while but it maybe that it stumbled at the get account on nagoya You don't need a nagoya account to do it. Possibly, maybe I was thinking of more fundamental involvement in the enterprise. apparently thought that he gave to you. not that I recall. I continue to believe that the wiki should be per PMC. Responsibility for oversight of content? I agree. which would requires some reengineering. ... search across the federated wikispace is a good thing. useful input to whom ever grabs the reengineering knife. The control loops on the current wiki are _way_ too open loop and the resulting systems is prone creating ear damaging noises. This is not a bad-thing(tm) and likely to lay waste to the good-thing(tm). - ben
Re: Wiki Administration
Noel J. Bergman wrote: Andy gave ... and Ben Hyde admin access. Wires got crossed someplace and that didn't come to closure. It's been a while but it maybe that it stumbled at the get account on nagoya step? No big deal. I continue to believe that the wiki should be per PMC. Infrastructure is poor site home for the editorial responsibility. Now that interlinking is working this is easier. Also solves the who should get the diff's email question. - ben
Re: ASF use of Instant Messaging
On Wednesday, January 15, 2003, at 03:05 PM, Sam Ruby wrote: Noel J. Bergman wrote: Are there any policies regarding IRC use, and is there an infrastructure participation in setting on an IRC channel for a project, or do we just go do something? Several ASF projects use IRC, including tomcat, mod_perl, Struts, Jelly, and others. It appears that at least those hosted by Werken maintain IRC archives to supplement the mail archives (I suspect that all do). My own views on this: 1) People should not be any more upset about the use of IRC than they should if two committers on a project happen to bump into each other at an ApacheCon and take the opportunity to discuss a problem that they are working on. Sweetly put. A nice use of what a graphic designer might call the whitespace. People do get upset when they suspect that the dialog about the work has gone into a private space. They get nervous. They get suspicious. They feel ostracized. They wonder what the rules are. They get peeved that people are changing the rules behind their back. Of course they should relax. Of course, they should ask. Yeah was there a conversation I missed? Huh, when did that consensus form? I once worked at a place were we fell into the convention of speaking of the work only in NNTP. It became odd to discuss it in the halls. We thought we were happy. In part because there was always the nagging thought, I wonder what X would say about that. I find it's important for people to take care to guard against the letting the dialog fork too far from the mailing list. This is hard to avoid. Particularly when some people are collocated and heavens to Betsy they eat lunch together - or worse have meetings with middle managers. One thing that helps if people are willing to step forward and testify. Say I got into a long conversation with A and B. We got to thinking This and That, and B admitted he's starting to like Those. While these admissions may make others feel nervous that these off the record discussions are happening they also help people to know that they aren't, to first order, seed crystals of a conspiracy. - ben
Re: fyi wiki statistics
Danny Angus wrote: Therefore 13% of all hits are people checking for new changes. So either we're all bored or theres a demonstrable need for effective notification. Yes I know, I was supposed to be looking at that too. d. It turns out if you build a event driven mail based notification system you shortly there after discover that it's too painful to use. The Wiki model results in editors writing changes so they can preview; and in tangles of nodes going thru periods of total chaos[1] as an editor attempts to make any changes that involve more than one node. Both these make the change stream very hard to read. I suspect that much of that could be resolved by sending mail with changes when the dust settles. I've used a similar model to trigger an automated build. When a change comes in scheduling an at job to do the build in ten minutes (canceling any currently scheduled build as I do that). Then the build would take off 10 minutes after the last passenger got on the plane. Something similar might be the best thing for the Wiki. The routine that computes the diff is GetKeptDiff. It depends on it's user having extablished dynamic extent in ways that make your brain hurt. It appears that the heart of that is done by invoking OpenKeptRevisions, with it's bogus argument. That loads the data needed to do the diff (the mimic of an RCS ,v file kept in the keep directory). It is probably easiest to just grab those files directly. You'd probably have to bump up KeepDays as well. - ben [1] It's though provoking to consider overlaying a XMLRPC or similar API so editors could create a private sandbox for doing real editing... did anybody mention that CMS is rat hole?
Re: fyi wiki statistics
On Tuesday, January 7, 2003, at 05:01 PM, Stefano Mazzocchi wrote: Greg Stein wrote: On Tue, Jan 07, 2003 at 11:53:52AM -0500, Ben Hyde wrote: ... It turns out if you build a event driven mail based notification system you shortly there after discover that it's too painful to use. The Wiki model results in editors writing changes so they can preview; and in tangles of nodes going thru periods of total chaos[1] as an editor attempts to make any changes that involve more than one node. Both these make the change stream very hard to read. I suspect that much of that could be resolved by sending mail with changes when the dust settles. Bah. Use SubWiki, check out the Wiki pages into a working copy, make all your changes, then commit them. Regular commit email sends the full bunch of changes. Simple as that :-) Oh, and maybe that's not under the GPL... 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 1) go to a page 2) edit it 3) save it Well duh, it's that what's cool about a wiki. I'm not that interested in revisiting that insight, nor do I think Greg is; instead I'm a greedy bastard and I think we want/need/will-be-much-happier(tm) with both models. [Ok maybe I'll indulge in a little revisiting that insight... You don't even make the dialectic as stark as it really is. The three step model requires few, if any, tools or skills folks don't already have; while the 4 step model requires CVS, commit rights, etc. etc.] What I'm trying to discuss is how to get a readable stream of deltas presented to volunteer proof readers. I think that's important. I've noticed so far that: - The RSS feed doesn't present the deltas. It appears that events are getting lost. - That an event driven email feed is too fine grain because it's almost like watching people type. This is a huge problem, I seem to be unable to edit a wiki page correctly in a single try - it usually takes me 3-5. I doubt any proof-reader could stand that! - It would be nice to have a way to make transactions over large numbers of nodes so the proof-readers see a transaction rather than the chaos of every flick of the pen. - That's really helpful when large transformation to the Wiki are done. - Possible solution: you can get part way to that end by putting some hysteresis into the edit-event - proof-reading-mail pipeline. - Thats analogous, and hence not too bizarre, to background build daemons that I've built and I suspect many others have seen or built. - It would be nice to have a CVS like checkout so editors could make changes locally. There are any number of large edits people might do if they can experiment on them privately. Greg Stein wrote: 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? :-) Well my brain got a lot smaller after I cut my hair, so bear that in mind. - ben
Re: fyi wiki statistics
On Tuesday, January 7, 2003, at 06:15 PM, Greg Stein wrote: On Tue, Jan 07, 2003 at 06:08:25PM -0500, Ben Hyde wrote: ... Greg Stein wrote: 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? :-) Well my brain got a lot smaller after I cut my hair, so bear that in mind. Well, geez. I could have told you that. Why do you think I keep my hair long? Projection. I'd assumed you were lazy, didn't like to talk to barbers, found it attracted women, and well you just really didn't have the time do to edit-compile-debug-loop addiction. At least those were my reasons and I can't imagine you'd need better reasons than mine!
Re: ApacheWiki RSS feed moved into apachewiki.cgi
On Saturday, January 4, 2003, at 03:39 PM, Andrew C. Oliver wrote: Right, I don't object to you contributing CVS mail patches. I just am not interested in doing it myself. I'm not trying to be nasty just convey Less talk, more action -Andy I'm not asking you do do anything, in fact I'm not sure what would be better.I'm reasonably sure what's there now is dangerous from a QA point of view - at least from my understanding of how to get good quality in an open source world. Attempting to silence critiques of the work is rarely healthy. Silent communities are either very low loyalty, or very authoritarian. - ben Ben Hyde wrote: I'm enjoying this rss service, but, this is not the equivalent of CVS mail; it's more analogous to getting a daily report enumerating which files in the software were changed. While at first I thought that wasn't a big deal, now it's clear that it pretty much precludes the proof reading that makes CVS mail such an aid to quality control. - ben On Saturday, January 4, 2003, at 11:06 AM, Andrew C. Oliver wrote: Thanks to everyone who helped... The apachewikitest.cgi is now just a link to apachewiki.cgi and what was just a test is now the real thing. So for those of you who do enjoy a good RSS feed you can do: http://nagoya.apache.org/wiki/apachewiki.cgi?action=rss For those of you who prefer to receive these by email, for now you can go here: http://blogs.cocoondev.org/stevenn/archives/000608.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheWiki RSS feed moved into apachewiki.cgi
I love wiki. Sander Striker wrote: Who is monitoring the Wiki content at the moment? The PMC should monitor PMC specific Wikis. Some of that is sketched out here http://nagoya.apache.org/wiki/apachewiki.cgi?WikiProjectPage ... below peanut gallery Steven Noels wrote: if someone can patch the RSS feed of the Wiki so that it has more sensible content, I assume we are almost getting there. moduse[1] has email notification, enable it. The email should go to dev@pmc.apache.org and consequential discussions can go there too. The email should include a diff. The RSS is merging change events, that's a mistake. - ben [1] Moduse is venerable software. Every time I turn something on it doesn't work quite the way I was expecting. The code defends it's self, and I love Perl.
Re: ApacheWiki RSS feed moved into apachewiki.cgi
I'm enjoying this rss service, but, this is not the equivalent of CVS mail; it's more analogous to getting a daily report enumerating which files in the software were changed. While at first I thought that wasn't a big deal, now it's clear that it pretty much precludes the proof reading that makes CVS mail such an aid to quality control. - ben On Saturday, January 4, 2003, at 11:06 AM, Andrew C. Oliver wrote: Thanks to everyone who helped... The apachewikitest.cgi is now just a link to apachewiki.cgi and what was just a test is now the real thing. So for those of you who do enjoy a good RSS feed you can do: http://nagoya.apache.org/wiki/apachewiki.cgi?action=rss For those of you who prefer to receive these by email, for now you can go here: http://blogs.cocoondev.org/stevenn/archives/000608.html
Re: Wiki RSS
My personal suggestion would be to find a way to partition the wiki pages per project and send those diffs to the various project mail lists. Yeah, then the different projects can make their own choices about lowering the barrier to entry vs. raising the quality bar. That is both something that the foundation should not own the responsibility for. Note that at the present moment oversight for the wiki - ah work product - is probably defaulting into the infrastructure PMC - that's not stable. This particular wiki software is quite lean, I suspect it's a little too lean - and GPL. As you've pointed out it's really a CMS, and as we all know that's a bottomless pit. If you change the script to compute the database path from url that invoked it. Then setting up multiple wiki's becomes trivial to automate. Inter-wiki linking was trivial for me to setup at my house. Though I see it didn't work out well for Andrew. Per project wiki would also enable some other experimenting. Something along the lines of http://httpd.wiki.apache.org / probably allows a range of sufficiently diverse and confusing futures. - ben The site of the true bottomless financial pit is the toy store. ps. Why is there no Starbucks at the ER? Why is there no shipping service at airport security?
Re: Wiki RSS
Is there an engine that can pull from RSS on one side, and e-mail on another? :-) It is probably the other way around. Email renders the events, RSS tends to summarize those events. A mail to RSS bridge is a variation on archiving. http://nagoya.apache.org/wiki/apachewiki.cgi?MailArchive I believe mailman's archiving does this. - ben ps. All protocols should have bridges to all other protocols. Email-Corba!
Re: [proposal] creation of communitity.apache.org
On Sunday, December 1, 2002, at 06:01 PM, Ben Hyde wrote: I've attempted to enumerate some of my concerns .. I'm done. - ben
Re: [proposal] creation of communitity.apache.org
//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
Re: [proposal] creation of communitity.apache.org
On Sunday, December 1, 2002, at 04:28 PM, Andrew C. Oliver wrote: Wow.. I really do feel like I'm at the Congress of Vienna. huh? (and yes I know what the congress of vienna was). It keeps coming back down to this: open (we sit on the left) closed (you sit on the right) and it really keeps being that simple. Exactly how does this have anything what so ever to do with open vs. closed?
Re: @apache web pages
It would be fun to have an Apache community aggregate of web logs, but I have trouble seeing how it serves the foundation's mission. Sorry to be a wet blanket... I'm concerned that if we create people.apache.org we create another inside/outsider boundary. I've got a handful of other concerns about this, but that's my primary one. Some other ones... I'd rather not co-mingles the Apache brand with the personal web face of individuals in various subparts of the community. Our mission. Creating great software. Puzzling out how to do that productively in cooperative volunteer teams. Releasing that widely under a license that is both open. Crafting an effective open license. One that doesn't entrap folks. I have to do a lot of A supports B supports C supports D before I get to the conclusion that D, building out a mess of committer web pages, supports A, the mission of the foundation. I'm concerned that a few highly vocal members might generate the impression that the foundation is taking positions that it's not. Consider Sam's web log with where he's been poking at RSS - that's not a ASF position. Consider my web log with it's rants on the wealth distribution - that's not an ASF position. The easiest way to avoid a star stage is not to build the stage. - ben
