On Tue, 2007-05-15 at 10:22 +0100, Danny Angus wrote:
0/ - Dismember the current Jakarta PMC - +1
1/ - Yes, preserve the brand - +1000
2/ - No. The commons PMC will run the commons project. A possible
Jakarta PMC will not have the attention that might be needed. - -1
3/ - -1 on the PRC. They have enough to do running their stuff and they
are not really interested in the day-to-day business of running a PRC.
Here is a thought: Do we need a PMC?
If we rethink Jakarta as "Java @ Apache", it will be our gateway for
Java interested developers into Apache. So what we need is sort of a
portal site. Basically a subset of projects.apache.org, branded for
Java. Those projects that feel they want to be on add a special tag (or
just Java) to their DOAP files and off we go. Automatic web site.
This is nothing fancy.
And we keep some mailing lists: [EMAIL PROTECTED] [EMAIL PROTECTED] Maybe
a [EMAIL PROTECTED] which is intended for people to ask about Java stuff and
get redirected. Needs maybe one or two more web pages.
Build the stuff and a nice front page that gets a news ticker similar to
what Jakarta has today, add the "these are our rules pages" which we
also have today, as these are the base for many other projects, ready.
Do we need a PMC? Or could this be an effort run by an existing PMC? For
me, infra would be the logical solution. Because, the whole portal thing
is mainly that. Infrastructure.
- create [EMAIL PROTECTED]
- let anyone interested subscribe
- get a repository which contains the site and hand out permissions for
it
- wait for a community to gather.
This is a largely stable effort. There is not much work in it (IMHO).
Why add the overhead of a PMC?
I'd like to contribute to that effort.
Best regards
Henning
> Hi,
>
> Ok, I've followed the commons TLP vote thread with some interest
> because it seems to impact directly on the end-game for Jakarta.
>
> I believe that we have to make some pretty fundamental decisions about
> that future before we can fully resolve the commons TLP issues.
>
> 0/ Do we agree that the end-game is dissolution of the Jakarta PMC and
> closure of the project?
> Pro - Draws a line under the reorg effort which has gone on for 3 or
> 4 *years*.
> Con - Removes the remaining tangible & historic links between former
> Jakarta sub-projects.
>
> 1/ If so do we wish to preserve the Jakarta brand? (the website and
> possibly general@)
> Pro - As Ted H. says "We should stop thinking of "Jakarta" only as
> an entity, and go back to thinking of it as to the ASF synonym for
> "Java", as originally intended."
> With this thought in mind around 10% of the referrals to
> james.apache come from jakarta.apache.
> Con - Others consider that the effort of maintaining the resources
> would be unacceptable to anyone.
>
> 2/ If we believe that the brand should be preserved should the commons
> TLP take ownership of the brand (if/when Jakarta PMC is dissolved)
> Pro - Commons is an active community which continues to fulfil the
> jakarta==java remit.
> Con - Commons is not necessarily interested in the brand or
> maintenance of its resources. (would people from other projects step
> up)
>
> 3/ If we believe that a commons TLP should not own the brand are any
> of the alternative options acceptable?
> - Retain the Jakarta PMC solely to maintain the brand
> - Move ownership of the brand to the prc (should they agree to have it)
> - Move ownership of the brand to projects.apache maintainers
>
>
> x/ Should we consult more widely the Members and/or the Board?
>
> My own (2c) opinion is that:
>
> 0/ Yes dissolve the jakarta pmc
>
> 1/ Yes preserve the brand
>
> 2/ If commons PMC would be comfortable with this it would be my
> preferred choice, *and* it would resolve the naming issue because the
> project could be "Jakarta Commons" which is a minor change from the
> sub-project name Jakarta/Commons
>
> 3/ If commons PMC would be against this then I think we should approach the
> prc.
>
> x/ Don't know
>
> In essence are we in favour of a revolutionary end or an evolutionary one?
>
> WDYT?
>
> d.
>
> ---------------------------------------------------------------------
> 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]
