Mailing-List: contact general-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Logging General" <general@logging.apache.org>
Message-ID: <004101c3d66d$3c3743e0$6401a8c0@hogwarts>
From: "Mark Womack" <mwomack@apache.org>
To: "Logging General" <general@logging.apache.org>
References: <5.2.1.1.0.20040108110708.02a7e2a8@mail.qos.ch>
Subject: [FINAL] Decision Needed Regarding Wiki
Date: Thu, 8 Jan 2004 20:58:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

With no objection, I will make the request to infrastructure Monday of next
week.  They can have the weekend off. :-)  And if anyone wants to pipe in
with a -1, you have the weekend to do it.

I proposed the logging-$subproject option because I feel that identifying
the parent project is important.  As we discussed, logging/$subproject would
be the best option, but it cannot be supported in the wiki, unfortunately.

Just to repeat the proposal:

1) Request infrastructure@apache.org create a new wiki for the Logging
project at:

  wiki.apache.org/logging

This will be a wiki for the Logging project.  We can put PMC/general items
there as well as links to subproject wiki's.
Change notifications for the wiki will be mailed to:
general@logging.apache.org

2) Request infrastructure@apache.org create a wiki for log4j at:

  wiki.apache.org/logging-log4j

The current Jakarta log4j wiki pages will also be ported/converted to the
new location so we won't have to recreate them.
Change notifications to the wiki will be mailed to:
log4j-cvs@logging.apache.org.

The general format for future subproject wiki's will be

  wiki.apache.org/logging-$subproject

with notifications being mailed to $subproject-cvs@logging.apache.org.  So,
taking log4net as an example:

  wiki.apache.org/logging-log4net
  notifications: log4net-cvs@logging.apache.org

----- Original Message ----- 
From: "Ceki G�lc�" <ceki@qos.ch>
To: <general@logging.apache.org>
Sent: Thursday, January 08, 2004 2:25 AM
Subject: Fwd: RE: Decision Needed Regarding Wiki


Mark,

Given Noel's message included below, we can even go for
wiki.apache.org/${subproject} instead of
wiki.apache.org/logging-${subproject}. Both options should result in
the same behavior wrt notifications. Craig McClanahan objected against
the first option, fearing name classes but apparently that is not a
problem because each subproject of Logging Services will have its own
Wiki in either case.

Anyway, given that we already have a positive vote for the first option,
let's
go with that if you like. In other words, please submit your request,
the one we just voted for, to infrastructure@ at the time of your
convenience.

>To: "Jakarta Project Management Committee List" <pmc@jakarta.apache.org>
>Subject: RE: Decision Needed Regarding Wiki
>Date: Wed, 7 Jan 2004 12:21:28 -0500
>
>The notification address is really the primary issue.  A single
notification
>address would allow the use of a single wiki.  Less work for infrastructure
>and less interwiki linking.  However, the downside is more traffic on a
>single mailing list, resulting in people tuning out.
>
>The Wiki URL is quite simple:
>
>   wiki.apache.org/$WIKI/$PAGE
>
>where $PAGE may have multiple path components.  Notification is associated
>with the $WIKI component, which does not support multiple path components.
>We could have:
>
>   wiki.apache.org/jakarta/commons/collections
>
>but that would be a wiki named jakarta and a page named
commons/collections.
>Therefore, any change would result in a message to the jakarta wiki
>notification address.  If we had:
>
>   wiki.apache.org/jakarta-commons/
>
>then changes to any of the pages could go to the notification address
>associated with that Wiki.
>
>Henri Yandell wrote:
>
> > All I know is that I get pissed off when setting up a link
> > of [ReleasePlan] is not allowed because some other project
> > has already chosen that name.
>
>Understood.  The Wiki Farm supports pages like:
>
>   wiki.apache.org/jakarta/commons/collections/ReleasePlan
>   wiki.apache.org/jakarta-commons/collections/ReleasePlan
>
>So you're covered either way.  The primary difference is notification.  On
>this issue, we seem to have two opposing perspectives.  Martin Cooper
wrote:
>
> > The wikis can be changed by anybody, not just committers. I don't feel
as
> > much of a need to keep an eye on people who have been voted in by the
PMC
> > as I do any old Tom, Dick or Harry messing with the wikis.
>
>whereas, Erik Hatcher wrote:
>
> > My main interest is in having page updates being mailed to a project
> > specific list so that content could be monitored.  Having content
> > changes for all projects go to a central list is not a good solution
> > to me - I would not want to be on that e-mail list.
>
>We need to resolve this issue.  For example, we seem to have an emerging
>consensus for:
>
>   wiki.apache.org/jakarta
>     - shared community pages, PMC pages,
>
>   wiki.apache.org/jakarta-$product
>     - product specific pages
>
>However, to where to we send the change notices?  And do we allow projects
>that don't want their own wiki to use the jakarta wiki?  Again, the
question
>is where to send notification messages, and we need to resolve this issue.
>
>Suggestions?
>
>         --- Noel

-- 
Ceki G�lc�

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp