incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Apache Incubator Proposal
Date Fri, 03 Jun 2011 04:00:24 GMT
Niall Pemberton <> wrote on 06/02/2011 09:07:31 

> The "Required Resources" section of the proposal is pretty
> minimalistic listing only two mailing lists, JIRA, Subversion &
> download site. While it is not necessary IMO to detail all
> requirements prior to accepting the proposal, it would be better to to
> give a more realistic picture of the scope of the resources required.

I'll update the wiki for this.  But I caution that much of this is pending 
discussion with the eventual project members.  It is not so much a matter 
of what assets we bring into the project and what assets are distributed 
in the project's deliverables, but more about how we structure the work. 
Some of this might also depend on how we ultimately relate to LibreOffice.

> Looking at the website I see the following:
>  - 146 projects (each of which has a mailing list)
>  - A wiki powered by
>  - Forums in 10 languages powered by

I'd like to recommend the following general approach:

1) Where possible, map active project collaboration artefacts (mailings 
lists, repositories, wiki pages, etc.) from to equivalent 
in the Apache OpenOffice project infrastructure.

2) For inactive projects pages, we might just archive the static HTML 
state of the project pages, for reference.

3) For end-user facing pages, we'll want to preserve an 
destination, on an Apache server.  So not the vanilla Apache project 
infrastructure, but an Apache OpenOffice branded end-user portal.  We'll 
need to be careful to preserve relative URL's, or do mod_rewrite redirects 
to preserve the thousands of internal and external links to these pages. 
If someone likes puzzles, this would be a good project.

Just throwing that out to prompt debate.  I'm open to other approaches.

> How many of these projects is it anticipated (best guess) will end up
> at the ASF? What is the likely number of mailing lists that will
> (eventually) be required?

Good question.  We haven't discussed this or reached consensus.  If anyone 
has a strong opinion on an approach, I'd love to hear it.  But it seems 
the poles are:

1) Bring over only what we absolutely need to build a release. 

2) Bring over everything at first, just in case we might need it sometime.

#1 looks like my wife's office.  #2 looks like my office.

> Will the user forums be hosted and supported by the ASF?
> Will the MidiWiki and its content be hosted and supported by the ASF?

Per above, I think we need to split the diamond.  We want to be good 
Apache citizens on the project infrastructure, the web site and tools that 
we use for collaborating in the project and developing and testing the 
code, tracking issues, etc.  But at the same time we realize that the web site is an amazing resource, full of end-user facing 
information.  If we tried to stuff that into an Apache project page, it 
would probably not work out well. 

Just throwing that out to prompt debate.  I'm open to other ideas here.

> has quite a few domain names (e.g.,
> etc.) - which (if any) of these domain names
> be transferred to the ASF?

The domain is  The variations are subdomains and these can 
be managed by whoever controls the domain.   Some of these are 
project-related, some are public facing.  I don't think we care about the 
project domain names, since there are not as many external links to them.

> I know there were good questions asked about trademarks in the 
> following thread:
> ...and the answer(s) were it will be cleared up during incubation. But
> it would be good to have an idea of whether this is going to be a big
> issue or not. On the face of it, it looks like there has been a more
> liberal policy than the ASF's current policy and there could be a
> large number of companies that might have to be dealt with. We have
> seen that dealing with a trademark issue with one company can take
> quite a bit of effort - could dwarf that. Specifically
> then:
>  - has the trademark policy been more liberal than the
> ASF's current policy?
>  - how many organisations have been granted permission to use the
> trademark in their products and services?
>  - If it has been more liberal, will the ASF allow this to continue
> and if not how will organisations that have been given permission be
> dealt with?

Do we need to be concerned with this?  In particular, if someone was given 
permission to use the trademark by Sun, or Oracle previously, does the 
assignment of the trademark to AFS negate the permission?  If not, then I 
think the question boils down to understanding better what AFS trademark 
policy is.

> Lastly a couple of comments..
> I thought Allen Pulsifer's post was good:
> ...especially the part about how dwarfs the scale of
> any other ASF project and I worry about whether we have the volunteer
> hours to first incubate this project and second to oversee and
> administer it post graduation?

When this question comes up I've been asking the commenter to give a 
reasoned estimate for how many volunteers will be needed.  I'm generally 
seeing that 20 core developers are needed for project maintenance.  Some 
suggest more is needed for incubation, but I think this might be a 
shifting parade of experts that we tap for specific tasks, to supplement 
the core project.
> I know that Rob said they didn't want to flood the proposal with IBM
> committers, but diversity isn't an issue for entering incubation -
> only exiting, so IMO it would be better to see those people listed
> from the start.

I'm thinking beyond Incubation requirements.  This is just good community 
management.  You don't want to start off on day 1 with a dozen IBM 
developers on the list and no one else.  It is imposing.  It suggests lack 
of diversity.  It discourages adding your name.   But trickle in the same 
dozen names over time, as others join the project as well, and there are 
no problems. That is my experience, in any case.



> Thanks
> Niall
> > regards
> > luke
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message