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]
