RE: Where we are.. continued..
Got a URL for one? --- Noel -Original Message- From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 16:36 To: community@apache.org Subject: RE: Where we are.. continued.. On Tue, 4 Feb 2003, Noel J. Bergman wrote: http://mapper.acme.com/?lat=34.036864long=-80.963427scale=10theme=Imagew idth=3height=2dot=Yes Thank G-d for trees. :-) Try SAR instead of this 2 visible band data - you may like the results :-) Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Verifying links
Are the *.apache.org sites ever scanned for broken links? I noticed to day that Eric Raymond moved his personal web site from tuxedo.org to catb.org, invalidating all links to tuxedo.org. See http://hurkle.thyrsus.com/~esr, which says My site has moved to http://www.catb.org/~esr/. Please fix your bookmarks accordingly. Just change `tuxedo' to 'catb' in each URL. There are links to his old URL, e.g., from http://jakarta.apache.org/site/library.html. In any event, I'm wondering about the systematic issue. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Verifying links
Erik, You are most welcome. And thank you for searching that list. :-) Although each PMC is ultimately responsible for their content, it does seem to me that it is a lot of redundant effort (and likely not commonly done) to scan for broken links. We have a link checker built into one of our products, but I'm sure that there are other open source tools for that purpose that could be batched, e.g., http://www.linklint.org/ http://validator.w3.org/docs/checklink.html Something like one of those could be batched from time to time, and the report mailed to the appropriate list. --- Noel -Original Message- From: Erik Abele [mailto:[EMAIL PROTECTED] Sent: Sunday, February 02, 2003 12:28 To: community@apache.org Subject: Re: Verifying links Thanks for the reminder to Eric Raymond's changes :) Just grep'ed httpd-*, site, site-tools, apr-*, incubator-*, asf-site, commons-* and found only 3 incorrect links. In any event, I'm wondering about the systematic issue. Do you think about a general link-checker installed on daedalus? Hmmm, is this really needed? IMHO this should be the responsibility of the content-producing group. cheers, Erik Noel J. Bergman wrote: Are the *.apache.org sites ever scanned for broken links? I noticed to day that Eric Raymond moved his personal web site from tuxedo.org to catb.org, invalidating all links to tuxedo.org. See http://hurkle.thyrsus.com/~esr, which says My site has moved to http://www.catb.org/~esr/. Please fix your bookmarks accordingly. Just change `tuxedo' to 'catb' in each URL. There are links to his old URL, e.g., from http://jakarta.apache.org/site/library.html. In any event, I'm wondering about the systematic issue. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Verifying links
Erik, Sorry ... one of our products wasn't referring to an Apache product, which is why I went on to look for some Open Source products to do the job. :-) I only used linklint so far; it's easy to setup and provides detailed reports. I just loaded it up onto one of my internal systems linklint -http -host project.apache.org -limit 5000 -doc sites/project.apache.org /@ Is that the best set of options, or is that a bit too naive? From the site report, it looks as if the best thing would be to put the results somewhere on daedalus or icarus, and post e-mail saying that the results are available. Would you be willing/able to help set it up? Would it be best to run it on one of the apache servers, or a third-party machine? I suspect that the configuration ought to be kept in a CVS module available to Committers, which could be updated to the linklint server before each run. Once setup, a cron job could kick it off at the desired schedule. --- Noel -Original Message- From: Erik Abele [mailto:[EMAIL PROTECTED] Sent: Sunday, February 02, 2003 15:35 To: community@apache.org Subject: Re: Verifying links Noel J. Bergman wrote: Erik, You are most welcome. And thank you for searching that list. :-) Although each PMC is ultimately responsible for their content, it does seem to me that it is a lot of redundant effort (and likely not commonly done) to scan for broken links. You're absuletely right, it would minimize a lot of redundant work and ensure that it is really done. However, since I rarely came across broken links on the ASF pages I just saw no need for it up to now, but I would be very fine with such a system :) We have a link checker built into one of our products, but I'm sure that there are other open source tools for that purpose that could be batched, e.g., http://www.linklint.org/ http://validator.w3.org/docs/checklink.html I only used linklint so far; it's easy to setup and provides detailed reports. Wich 'of our products' do you mean? Sorry, don't know every project of the Jakarta world :-( Something like one of those could be batched from time to time, and the report mailed to the appropriate list. As said above, would be handy to have such a tool; just go for it ;-) cheers, Erik --- Noel -Original Message- From: Erik Abele [mailto:[EMAIL PROTECTED] Sent: Sunday, February 02, 2003 12:28 To: community@apache.org Subject: Re: Verifying links Thanks for the reminder to Eric Raymond's changes :) Just grep'ed httpd-*, site, site-tools, apr-*, incubator-*, asf-site, commons-* and found only 3 incorrect links. In any event, I'm wondering about the systematic issue. Do you think about a general link-checker installed on daedalus? Hmmm, is this really needed? IMHO this should be the responsibility of the content-producing group. cheers, Erik Noel J. Bergman wrote: Are the *.apache.org sites ever scanned for broken links? I noticed to day that Eric Raymond moved his personal web site from tuxedo.org to catb.org, invalidating all links to tuxedo.org. See http://hurkle.thyrsus.com/~esr, which says My site has moved to http://www.catb.org/~esr/. Please fix your bookmarks accordingly. Just change `tuxedo' to 'catb' in each URL. There are links to his old URL, e.g., from http://jakarta.apache.org/site/library.html. In any event, I'm wondering about the systematic issue. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we've got a proposed solution - hierarchy
Oversight of content relating to a specific PMC should be the repsonsibility of said PMC. That is one view. There may be others. I believe that there is interest in having a consensus on policy first, and then a solution. Not too many people have spoken up one way or another on that issue. It is not clear that PMCs like [Web Service] have any Wiki content as of yet. FWIW, they do. Therefore, I propose a hierarchy of Wikis. Actually, I think that the topology is better viewed as a (potentially heterogeneous) network of federated wikis rather than a hierarchy. :-) The ApacheWiki will remain with it's 3 official WikiAdmins The three WikiAdmins are neither official nor representatives of a proper oversight body. The most logical group would be those who are responsible for the site module, and I don't believe that they want it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
Costin, I see several differences between mailing list and Wiki content: 1. posting policy If you manage your Wiki with Wiki pages in conversation mode, shouldn't you want similar control over Wiki posting as e-mail posting? 2. representation I do see wiki as a transcript of opinions and ideas of a user. E-mail is signed by the sender, and the presumed representation is that it is the opinion of the sender. If you want your Wiki to be a transcript of user opinions, don't you want the content coming from specific users to be clearly represented as such? Also, there are two types of Wiki pages: one represents the opinions of individual users, but the other reflects a gestalt view. I've done both, and I prefer the latter; the Wiki best practice known as document mode. A document mode page may not represent the official position of a project, but nor can it be said to represent individual opinions. IMHO what's important is to find a way to make it clear and agree that wiki is not the oficial document of apache I agree with Danny Angus' proposal that the Wiki code place a disclaimer in a page footer. 3. ownership In my opinion, the Wiki is part of the project documentation. It may be less official, it may be user-to-user, but it is part of the project documentation. where do we draw the line - after the oversight is in place. If someone submits a web page for the Tomcat help section stating as fact that Tomcat sucks, that it won't install properly, that the developers don't answer questions, that members of tomcat-user@ are rude and unhelpful, are you going to commit it? We have both seen those sentiments expressed on the mailing list by a handful of vocal malcontents. 4. Mailing list content extends over time. Wiki content morphs over time. The ability to morph content to reflect an evolving consensus is one reason why document mode pages represent Wiki best practice. I consider it to be the benefit of a Wiki, contrasting sharply with a mailing list, bulletin board or weblog. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we've got a proposed solution - hierarchy
Dirk-Willem van Gulik: Noel J. Bergman wrote: The three WikiAdmins are neither official nor representatives of a proper oversight body. The most logical group would be those who are responsible for the site module, and I don't believe that they want it. Well - the PMC's could each volunteer one wiki admin; just like we now have mailing list moderator volunteers - and delegate the task to them. I don't mean for the per-PMC Wiki oversight. I was refering to his suggestion that the three current WikiAdmins would continue to monitor the current Wiki after the per-PMC Wiki would be installed. My understanding is that according to the per-PMC Wiki policy, unless a PMC wants oversight of a Wiki, it won't exist. The current Wiki, not being under any PMC oversight, would go away. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
Now that it appears that a consensus is brewing, I'm finally posting this message in public --- There appears to be a consensus for a Wiki per-PMC approach until some other Wiki technology might provide some other segmentation schema for oversight. The purpose is to ensure that all content is overseen by some PMC. With the current Wiki, there is no clear designation, no clear mechanism for notifying the right people of changes to content they oversee, and there are pages that aren't overseen by any PMC. If the infrastructure team is willing to prepare a per-PMC Wiki structure as 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 With appropriate redirects to nagoya, if that is where the Wiki will continug living for the present. This also implies that if the Cocoon PMC were ensuring proper oversight they could redirect http://cocoon.apache.org/wiki to http://wiki.cocoondev.org. We will need interWiki links to support such things as: AvalonWiki:IoC JamesWiki:MailetAPI etc., and could use an interWiki link to send people to the usemodWiki sandbox to play, rather than play on our server(s); the same might be true of some other pages. I don't see this as a shift in policy, simply a change in implementation to address the need that at the ASF content requires oversight. Any content engine must support, at a minimum, two related features in that area: 1) Associate content with the appropriate PMC 2) Allow change notification via e-mail Note that I did not say *how* either of those things must work. With the current Wiki, the per-PMC Wiki approach seems to be the best way to meet those requirements. I propose that the canonical URL for normal page access be /wiki/page, regardless of which Wiki is deployed. As a technical matter, and also in terms of planning for change, I believe that with a minor change to the perl code, and use of mod_rewrite, we can hide the Wiki implementation in the URL. One would to do this would be something like: On daedalus: RewriteRule ^/wiki/(.*)$ http://nagoya.apache.org/PMC-wiki/$1 [R] On nagoya: RewriteRule ^/PMC-wiki/(.*)$ /PMC-wiki/apachewiki.cgi?$1 If we did a proxy instead of a redirect: RewriteRule ^/wiki/(.*)$ http://nagoya.apache.org/PMC-wiki/apachewiki.cgi?$1 [P] ProxyPassReverse /wiki/ http://nagoya.apache.org/PMC-wiki/ we could make it seamless, but that would put more I/O load on daedalus. SubWiki would be easy to handle. We wouldn't need a rewrite on nagoya at all (even assuming that nagoya would be the host). JSPWiki (Cocoon), on the other hand, makes it a bit trickier, because they use URLs like: /Wiki.jsp?page=$1 /Edit.jsp?page=$1 /Action.jsp?page=$1 But that is easy enough to handle, because of the predicate that the only URL that we care to preserve for bookmarks is the normal page reference. In any event, the last portion of this message is something that can be worked out on infrastructure, if the overall policy is adopted. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
Ben,
There may be some minor twists, but I didn't say it would be hard. :-) And
I am going to stay as far away from that code as possible. Tim O'brien,
though, already has some useful patches, including one to require people to
set their preferences before they can post to the Wiki.
To start, I think that we'd want to clone the current Wiki, on the grounds
that it will be easier for those of us who have data in it to delete the
extraneous pages than for Pier to figure out what each of us wants.
--- Noel
-Original Message-
From: Ben Hyde [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 01, 2003 16:46
To: community@apache.org
Subject: 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
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. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we've got a proposed solution - hierarchy
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. I'm sure we can make the migration work. :-) We wouldn't remove any content until after the new Wiki are in place, along with the interwiki setup. Then we'd go to the old Wiki and insert #REDIRECT directives to point to our new Wiki. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
What I mean here is -not- the ASF cultural thing of having things validated by your peers; but the oversight of the type that the ASF as a US incorperated is supposed to maintain. specificaly of the type which gets us in real-live(tm) trouble; warez, child-porn, list of license keys, etc. - is a PMC or similar body who duly provides oversight to any abuse. This is a weaker oversight requirement than ensuring that information is accurate, or that more subtle content concerns are managed. If setup properly, scanning diffs to see that there aren't warez, porn, license keys, etc., shouldn't take very long. We're talking about 30 changed pages per day on average. To do the above does not require any structural changes. It simply requires that some group be established that watches wiki changes for violations of the above content rules. That group, for now, could be a sub-group under the auspices of the infrastructure PMC. Is that level of oversight sufficient, or do we need for each page to be under the oversight of a project PMC related to that content? The later introduces a whole different set of issues. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
Justin, The wikidiffs@ list received 77 emails yesterday. That's a *lot* of traffic for a small group to handle reliably. I certainly can't keep up with that. Understood. One problem is that changes aren't merged. I probably do a half dozen minor Wiki updates before I finish with an edit. I'd prefer that diffs for oversight were only generated after pages settled. Obviously, that requires a code change, and I'm not going to touch that code. That is something to consider mentioning to Greg for SubWiki. :-) Even with the oversight approach that we both agree upon, this could be an issue. Wiki edits are likely to be made iteratively, whereas when I submit code to the CVS, the edits are already merged. Imagine if we had to follow commits made directly from emacs on C-X C-S! Ouch. :-) And, that's with only minimal activity on the wiki. I don't think a centralized group of oversight scales for something the entire ASF would use. I think the oversight belongs with the people are responsible for the content. I'd rather not see the infrastructure committee (or any subset thereof) have to make the determiniation on what is proper or not. I'd much prefer PMCs being responsible for sections of the wiki that their projects are using. I agree. But the message, as posted, didn't deal with improper content. The issue it raised was simply about oversight from a corporate liability perspective, essentially guarding against illegal behavior, and that is what I responded to in my reply. I mentioned my observation that it was a relatively weak standard for oversight. If more oversight is necessary, a different set of issues comes up. I didn't pick infrastructure to do the work. I mentioned a group under the auspices of infrastructure, since infrastructure is the only group that spans the organization. I certainly didn't mean that the work would be done by you, Brian, Manoj, Pier, et al. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Student Section on wiki
I wonder how this ended up on wikidiffs@ Looks like http://nagoya.apache.org/wiki/apachewiki.cgi?TheStudentResearchPage was something that Andy started. My guess is that Master Townhill e-mailed wikidiffs because of Andy's comments on http://nagoya.apache.org/wiki/apachewiki.cgi?WikiAdmin. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Public... (Was: Re: Adding community@ archives was Open community)
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] rg Do you still need to do something to enable searching? Doesn't seem to be available. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Open community (was ... secret discussions ...)
In the community@ archives you can find the vote on whether this list should be open or closed. WHAT archives? As I have commented on before, eyebrowse has none for community@ (http://nagoya.apache.org/eyebrowse/SummarizeList?listId=108). Are they elsewhere? If so, where? --- Noel
RE: Adding community@ archives was Open community (was ... secret discussions ...)
We're not really trying to hide anything. What you might be able to attribute to malice, attribute to, umm, absentmindedness. For the record, malice never occured to me as an option. I'd asked about archives previously, without a response. So when the comment was ever so casually made that we could just look in them, naturally that perked up my ears, and renewed my interest in knowing where such are located. --- Noel
RE: Wiki Administration
The life of a dyslexic is full of surprises. That should have read This is a bad-thing(tm).. I had figured as much from the earlier part of the paragraph. :-) I assume that as soon as we create per PMC Wiki those PMC would discover that they have pride of craft in the content of that Wiki. That will trigger oversight. Fair enough. I check RecentChanges several times daily, so my attitude may be conditioned by the fact that I *am* checking our pages for changes. I admit that if Project X is going off on a rant, I would have no idea. Same thing with their mailing list. If I saw something odd in RecentChanges, I'd probably look, which is why I've noticed that people have been reorganizing by the delete/create method, rather than renaming. But I also learned a neat trick last night with this Wiki. The #REDIRECT WikiWord trick. Learn something new every day. I'll probably make use of that one. I don't have any desire to keep anybody from engaging direct editing of the content. The trick is getting the right balance of lots of voices and a cooperative group of high mutual regard that keep the thing on track. A balancing act. Agreed. Again, I'm hoping that we can ride it out with useModWiki, and use the learning experience to drive SubWiki features. --- Noel
Wiki Benefits
People can do the same with patches on mailing list; and seem less likely to abuse that. Perhaps the simple validation (and display) of a valid email address may do the trick. You are concerned about abuse. I don't disagree, but the mailing lists are also capable of being abused. I would not complain if in order to edit the Wiki, a user had to subscribe similarly to how they subscribe to mailing lists. I've already raised the notion of SubWiki adding access controls, and that could be part of the model. But right now I am not seeing abuse (glancing around for some wood to knock on), and the benefits are real. IMO, restricting the publishing medium to either a mailing list or the Committer published web site creates a tremendous more amount of work for Committers to apply patches, removes the self-empowerment element from the users, and thus a psychological incentive for them to help, and delays the availability of the content. An e-mail message is static. Once published, it lives as-is. It cannot be edited. It cannot be refined. It cannot be corrected if it is in error, or if the situation changes. It exists in an unstructured archive. A Wiki page is a malleable part of structurable content. The Wiki enables users who have worked out solutions to a problem to post those solutions in a user helping user mode. Publishing the solution once to the mailing list means that users have to search the archives, rather than have a more structured organization to helpful content. We're more likely to harvest e-mail content and refine it on the Wiki. Even for committers with CVS access, the Wiki is much, *much* faster for collaborative editing of documents that are works in progress before committing them, again through the whole process. It isn't even close to being only one order of magnitude easier. I can edit a page in seconds without having to edit the xdoc, commit the xdoc change, build the web site, commit the web site changes, log into daedalus and update the site. I can't get away with less than 5 minutes per change. The web site build takes that long, by itself. I am absolutely convinced that we have a lot more collaboration on documents because of the Wiki. I do agree that the Wiki isn't a discussion medium. Our Wiki area has the following notation: Please use the James mailing lists to discuss the content of these pages. The purpose of the Wiki is to record and edit plans/proposals/notions that are discussed on the mailing lists. And periodically, we could harvest suitable Wiki content, and move it into the xdocs-HTML publishing process. Right now I am taking a check list of changes that was maintained quickly on the Wiki, and moving it into xdocs for the next Release. --- Noel
ASF Release Policy?
Is there a uniform release policy for the ASF? For example, here are two documents: http://httpd.apache.org/dev/release.html Technically, any one can make a release of the source code due to the Apache Software License. However, only members of the Apache HTTP Server Project (committers) to project can make a release designated with Apache. The primary control has to do with the release quality: alpha: When a release is initially created, it automatically becomes alpha quality. beta: at least three committers have voted positively for beta status and there were more positive than negative votes for beta designation. GA: at least three committers have voted positively for GA status and that there were more positive than negative votes for GA designation. No mention of PMC involvement, for example. On the other hand, Jakarta: After a new release is built, it must be tested before being released to the public. Majority approval is required before the release can be made. Once a release is approved by the Committers, the Project Management Committee can authorize its distribution on behalf of the Foundation. - from http://jakarta.apache.org/site/decisions.html. Which is interesting, since most people apparently aren't aware that Jakarta sub-projects are supposed to get Jakarta PMC approval before distributing a Release. The XML Project has the same text as Jakarta, minus the sentence about the PMC requirement. I have no idea what other projects require. So ... finishing where I started: is there a uniform ASF policy on this issue? If so, what is it, and where is it documented? :-) --- Noel
RE: You can at least forward my comments to these secret discussions about wiki
a friend of the court brief for the Board vs. Wiki. Board vs. Wiki? That's somewhat amusing in its timing, considering that the Chairman of the Board, as a private individual not in an official capacity, (a) is the author of SubWiki, (b) posted a message to community@ in support for Wiki use just minutes ago, (c) has expressed his willingness to address concerns regarding issues integrating Wiki technology into a managed environment. Words create images. Hyperbole can be useful at times, but Board vs. Wiki paints a grossly distorted image that is damaging to any constructive discussion of the subject. I have had discussion about the Wiki with multiple members of the Board. Each of them expressed support for the Wiki, although with some reservations regarding best use, oversight, or other personal views. And those are just that: their personal views. I am not aware of the ASF Board, as an official body, having said word one about the Wiki. Nor do I detect anything regarding the Wiki in their meeting minutes. Beyond that, I'm sensing hostility that doesn't make any sense. --- Noel
RE: Wiki Administration
In my book Andy (Oliver, not Clark) is the master of Wiki... Andy gave myself and Ben Hyde admin access. From what Andy is saying, his plan is to give that to anyone (within reason) who asks. I don't particularly have a care, other than that people ought to know that such things as deleting and page renaming are possible. --- Noel
RE: Weblogs and Obstructionism WAS: Re: weblogs on apache.org
Costin, Consensus or at least a majority :-) I believe he was using the common dictionary definition, not refering to unanimity. [agregating blogs ( or subsets ) from the apache community] is a very different and IMO more important issue. Putting this information togheter and making it accessible may be _very_ important for the community and apache projects. One of my suggestions was that Andrew (and others) should submit a list of features that Greg might add to SubWiki. Greg expressed interest in adding such features as people think useful.
ASF use of Instant Messaging
Justin, Sander, and I just chatted on IRC. This reminds me. Many of us recognize the benefits of instant messaging, via whatever method. However, when I first started contributing to James, one of the things that came out from one longer time Community member was a great deal of ... displeasure ... over the fact that a some of us might communicating via any mechanism other than the mailing list. On the other hand, I have repeatedly noticed that when instant messaging is available, it has multiple benefits: - people spent more time working - people felt that they had more immediacy to their colleagues - people felt that they were getting better feedback - people felt more collaborative - people built friendships - misunderstandings were more likely to be corrected before significant ire was displayed I could go on. These benefits seem valuable to me, especially to bring a geographically dis-joint community closer, but I also acknowledge the value of open and archived discussions, so that everyone may participate. 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). Finally, is IRC the right tool, compared (for example) to a Jabber server? Similar to Andrew's establishment of the Wiki, does it make sense to install jabberd (http://jabberd.jabberstudio.org/) for ASF projects (in the long run, I'm thinking that James ought to support the Jabber protocol). --- Noel
RE: email notification done...sorta
Yup. Python people *and* Subversion people. :) Well *that* much I knew. :-) The association between Collab.Net and the ASF isn't obscured. I keep wondering if some of the tigris.org projects will migrate to the ASF. There appears to be a lot in common, including people. ASF uses (or will use) Subversion, SubWiki, Eyebrowse, and could use Scarab. I haven't yet figured out if we can make use any of anzu with James. Tigris uses Lucene, Velocity, Apache, Turbine, ... Of course, I see that there are key differences between Tigris and the ASF (including community structure, legal issues, etc.), but I would think that some of the more mature Tigris projects would make for good ASF projects. This is so obvious a question, it must have come up before, but there don't appear to be archives for community@ in eyebrowse. --- Noel
RE: Do vs. Talk (Re: email notification done...sorta)
Jeff, Unless I missed a discussion elsewhere (I'm only on community@ and infrastructure@, as well as project lists), Andy appeared to be complaining about (a) people asking for changes to the Wiki without contributing patches, and (b) the current lack of consensus on how to integrate push-model into the Wiki. This seems ironic to me, since Andy talked about how the Wiki would help non-account holders to develop documentation, but appears to have had little patience for the fact that such Wiki USERS might want changes that they wouldn't implement. This is a good example for why One Man Codebases don't work; it takes a Community. Perhaps it was said elsewhere, but I didn't see anyone say Wiki? Yuck. Get rid of it! What I did see were people saying, Great! And thanks! But now that we have one, we want to make even better use of it, and so we need ... And those comments seem to come from people who are using the Wiki. --- Noel
RE: Do vs. Talk (Re: email notification done...sorta)
Because wiki's tend to fill with content rapdily, once you use them for a little while you are pretty much locked in. Counterpoint? Personally, I'm getting mileage out of UseModWiki, despite its issues. I wouldn't want to have to move every page in the Wiki, but I could cut paste the content for our section if I didn't have a migration tool. At the moment, the content volume might not warrant a tool, and if the content volume did, it could certainly be written. --- Noel
RE: wiki data migration (was: Do vs. Talk)
Greg Stein wrote (technical details omitted): *if* we migrate to SubWiki or some other Wiki, then we can get the data out of UseModWiki. Sounds like your approach follows the truism that in the worst case any open source code that can read its own data can be instrumented to become its own migration tool. What would you guess is the relative effort to preserve the history? I'm just wondering if the history value at the cut-over point will be worth the incremental effort, unless you want to do it anyway as a proof-of-concept for similar migrations. --- Noel
RE: email notification done...sorta
Its too bad we don't have any decent perl programmers. I'm apparently the master PERL programmer here. The rest of you are all talk. I'm getting quite sick of your you're all talk attitude. Chill the hell out. damn. I was joking around. sheesh. That was not at all clear from your note. I was going to reply that perhaps the choice of usemodwiki was a good one as a turnkey thing, but perhaps not the best choice for the long term due to the lack of competent Perl programmers willing to contribute. At the moment, Danny Angus and Rick Bowen are the two who've stepped forward, and both of them have other primary involvements, not to mention this being the first week that many people are back from spending time with family. On the other hand, we've a lot more competent server-side Java contributors. As for flame bait, I don't get the joke. Isn't Why do we still have this rediculous JakartaVelocity project? JSP long superceded it! a simple statement of fact? --- Noel
RE: email notification done...sorta
For those of you who are humor-impaired, or not aware of the Perl Acme meme, the Acme::* line of modules on CPAN are jokes. Aha! :-) I knew there was a joke in there somewhere, but that little tidbit does help to illuminate the punchline. --- Noel
RE: email notification done...sorta
http://www.freeroller.net/page/acoliver/20030108#when_is_community_not_a And having still read over his web log, I'm really not sure why. Seems to me that: - the wiki is a good thing, and is being used. otherwise, no one would have made suggestions or cared. - as indicated by stop replying to me with just more requests, JustDoIt, he took each request personally, rather than as a general request, and didn't take into account whether the person making the request was appropriate to implement the change. The fallacy of Open Source is the source code is available, do it yourself. - he didn't get help from the relatively few Perl programmers in an immediate timeframe over the course of Xmas and New Year's. - he was criticized for a message that he made in jest, but which wasn't at all obvious in that intent. Just Do It is a great ad slogan, but it doesn't seem to me to always be the appropriate model for group projects. Yes, it makes things happen. But when people are actively discussing an issue of communal interest, it makes sense to me that the issue be discussed, various ways to doing something examined, tradeoffs weighed, and then execute a change based upon some concensus. Otherwise, when more than one person cares about a subject, Just Do It results in one person's vision being realized, and a cycle of potentially conflicting changes necessary to stablize the code. Am I missing something? 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? --- Noel -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 08, 2003 13:12 To: community@apache.org Subject: RE: email notification done...sorta Andy unsubscribed btw.. http://www.freeroller.net/page/acoliver/20030108#when_is_community_not_a Mvgr, Martin -Original Message- From: Joe Schaefer [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 08, 2003 19:12 To: community@apache.org Subject: Re: email notification done...sorta Noel J. Bergman [EMAIL PROTECTED] writes: [...] I was going to reply that perhaps the choice of usemodwiki was a good one as a turnkey thing, but perhaps not the best choice for the long term due to the lack of competent Perl programmers willing to contribute. At the moment, Danny Angus and Rick Bowen are the two who've stepped forward, and both of them have other primary involvements, not to mention this being the first week that many people are back from spending time with family. I was/am also planning to help, and I did look over the usemodwiki source to get acquainted with it. However, I don't have any experience with wikis, nor with RSS, so I also need to bring myself up to speed on the technology- according to *my own* (free) timetable. Part of that learning process is simply watching how experienced people operate, and then trying to mimic their behavior. Or not, as the case may be. On the other hand, we've a lot more competent server-side Java contributors. Right. To my knowledge, there are only a dozen or so active committers that work on perl-related ASF projects. -- Joe Schaefer
RE: email notification done...sorta
Justin, I don't particularly care which Wiki we use, so if one has benefits over the other, great. But I would like to see the content migrated from usemodwiki to Subwiki if that's what is going to be used. How viable is it to machine migrate the content? --- Noel
RE: fyi wiki statistics
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. grin Does this mean that Subversion is coming soon to replace a CVS repository near us? Not that updating a Wiki that way is in the spirit of Wikis as I know them, but I'm looking forward to Subversion. --- Noel
RE: Tapestry incubation
I'll bite ... what is Tapestry? --- Noel -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] Sent: Saturday, January 04, 2003 17:54 To: community@apache.org; Jakarta General List; general@incubator.apache.org Subject: Tapestry incubation no-connotation requestedaction=subscribe, ignore Please subscribe to general@incubator.apache.org if you are interested in participating in the Tapestry incubation process. Thank you, Andy /no-connotation
RE: ApacheWiki RSS feed moved into apachewiki.cgi
I am interested in content quality. I would probably subscribe to the 'wiki-changes' list, since that would push the content under my nose instead of having me actively reading each changed page online. Right, that has been my point about push model communication. But do you really want to have every change pushed into your mail box (this is actually easy to do with usemodwiki), or just those pages that interest you? Every few days I check to see the RecentChanges list, but I primarly skim it looking to see if pages related to projects I care about have changed. If the Wiki gets lots of use, reading all changes would be like subscribing to every CVS change made in every module all over Apache. At that point the perceived signal to noise ratio for most people would be rather low, IMO. It seems that Andy feels that an RSS feed is the solution to this problem. --- Noel
RE: Wiki RSS
Yeah its still on my radar Noel, but as you say, I have to bond with my kids... If I were you, I know where my priority would be. :-) Happy Holidays. --- Noel
RE: [FYI] Cocoon Wiki
no idea what nagoya is but Steven has a pretty fat server behind cocoondev According to the machines page, Nagoya is a Sun E4500. I don't have any more clue than that (would be curious to know the actual configuration), but E4500s tend to be pretty powerful beasts. --- Noel
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. But I have no idea on how difficult/feasible that is with the current software. How good a PERL coder are you? [Actually, Danny Angus had mentioned that he might look at this, but this time of year is busy for everyone] There is a page record. It seemed to me that it ought to be feasible to add a field to each page record with a mailing list address, and then mail change notifications from the edit, when the edit is not minor. This would be additional to what appears to be an admin request/requirement for changes to be posted to an mailing list for logging purposes. But my PERL is infrequently exercised, and I haven't had time to look at the details of implementing the change. --- Noel
RE: Wiki RSS
I'd much prefer mailing list notifications over RSS feeds. These types of notifications shouldn't be pull. Is there an engine that can pull from RSS on one side, and e-mail on another? [Something to add to the nice-to-have list for James] --- Noel
RE: HotJava and EOL
Andrew, Around HotJava, the browser application? I suspect relatively little. Around the component? I know several projects that would love to see it resurrected. --- Noel
RE: Wiki Wiki (has been set up)
Andrew, Hallalujah! I have been asking about a Wiki on and off for months, and was told as recently as a week ago that there were security reasons for not yet having one. Kudos for just getting this done! I am not familar with the code of this particular Wiki engine. What would it take to attach an optional mailing list attribute to a page so that when the page is edited, a notice can be driven to the mailing list? Or so that a daily/weekly report could be generated containing that info? The primary communication mechanism is the push-model mailing list. A Wiki is basically pull-model. I'd like to see push-model notification integrated into the Wiki, which is something I am considering adding to vqWiki when I've some time. --- Noel
RE: [ot] domain registrars
We transfered all of our domains from NSI to BulkRegister, and we have been very happy with BulkRegister, so far. --- Noel
RE: Wiki Wiki (has been set up)
Andrew, There is already some sort of e-mail notification capability built into the Wiki, although there seems to be some question over its usefulness on the UseMod wiki site. But that at least provides us with a starting point. I've downloaded the source code, and will have a look see next week. There appears to be some sort of database format, so perhaps I can add a field to the page record as a quick hack. I'm not much of a Perl coder, so if anyone IS a serious Perl coder, I'll bet that they could hack it in posthaste. --- Noel
RE: HotJava proposal on the Wiki
Andrew, With respect to the proposal that Sun be approached to turn over HotJava to the ASF, do you have a suitable person at Sun to fulfill your ContactAtSun - We'll need a contact at Sun in order to make this happen role? Is Sun aware of the interest? --- Noel -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] Sent: Saturday, December 21, 2002 17:19 To: community@apache.org Subject: HotJava proposal on the Wiki http://nagoya.apache.org/wiki/apachewiki.cgi?HotJavaProposal
RE: ASF Member/Committer AUP
you might want to include Maven/Jelly in the section on bulding, which currently has only Ant. I've invited Mavenites to contribute, I've not recieved anything. Ask Dion Gillard specifically. He's doing a lot on documenting Maven. Other topics for your list: What is GUMP (just an example, I know what it is)? Yes links to GUMP (http://jakarta.apache.org/gump) is a good idea. Though I hear its not very good (J/K) ;-) I've heard of some that don't appear to be linked from any page that I've noticed (probably one for thie discussion, for example :-)). No they are linked quite clearly from the page that says mailing lists Really? Where is the reorg mailing list, for example? :-) I was refering to the fact that some are missing from the lists, not that all of them are. And the non-project specific ones that are ASF related were what I had in mind for your document. In general, I'd want a document that explained the existing policies, mechanisms, and best practices, including where to go for more detail. http://jakarta.apache.org/site/guidelines.html Been there, read that, own the t-shirt. ;-) That isn't linked with www.apache.org/dev, for example. Having one central starting point to collate all of the myriad bits of information for Committers is what I was getting at. --- Noel
RE: [proposal] creation of communitity.apache.org
Sam Ruby wrote: The ASF has supportted .forward files for e-mail for quite some time. Would the mere act of putting a one line .forward file into your ~/public_html directory with your favorite URL be OK? A bit more work for httpd than your ~name/public_html/community or some such proposal, but combined with your suggested merger of http://www.apache.org/~jim/committers.html and ~coar/people.html, it would appear to address most objections I noted on the thread. One that it doesn't address is Ben Hyde's view that that the chaotic mess, where there are committers who don't even know that they can create a public_html, much less feel encouraged to do so, is different from a seeming endorsement of community pages. Stefano Mazzocchi wrote: My personal experience shows that promoting personal context helps creating more friendly communities. Do you believe that someone's first thought would be to look at some centralized index, or at the project's home page? What if the contributors list on each project were similarly (and optionally) instrumented as proposed by Sam Ruby's suggestion (above)? Or is that an infrastructure question, along with IM and Wiki topics? --- Noel
RE: [proposal] creation of communitity.apache.org
Justin, if you would like to put forward a set of rules, guidelines, and suggest an enforcement mechanism, I would be inclined to endorse it if it would further consensus. It occurs to me that if people want to guide the content of the ASF hosted personal page, there could be a DTD, and the pages could be generated from an XML file using a consistent look as is done for projects. The DTD could define an optional reference to an off-site page for individual expression (personal pages, blogs, wikis, whatever). You'd opt-in by creating the XML, have guidance as to the normal content, have a standard way to refer to more personal data as desired, and it would be clear that such other data was not part of the standard ASF material. That provides a standard opt-in mechanism, guidance on content, ought to encourage the kind of information Stefano has in mind, and provides for freedom of expression on an indirect page. Does that satisfy anyone? --- Noel
RE: [proposal] creation of communitity.apache.org
ROUS wrote: uniform education of (new) committers is one of the purposes of the incubator project. documenting these things for all, including existing committers, is as well. As a new committer, I not only appreciate that view, I want to know where to find the info! :-) --- Noel
