incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Explanation of the extra pain (was: Two other issues to discuss for Subversion)
Date Fri, 13 Nov 2009 20:23:04 GMT
In reference to Gilles' question about why we normally ask podling to
take on a bit of pain for double-migration, I think Leo answered that
very well [on this other thread]. That the reason focuses mostly
around making representations to users. "this is an Incubator project,
not a full Apache project"

Or at a minimum, he provides a great place for us to start answering
*why* we ask podlings to do this.

I believe that we have given Subversion a "pass" for a several reasons
(mostly restated/clarified from Leo's email):

1) we all believe Subversion will graudate, so we have no risk around
this podling pretending/representing an Apache project/name and then
bailing out
2) we do not expect Subversion to remain long (my goal: graudate
December; worst case January), so the need for particular care around
branding is not worth the cost for such a short duration
3) we trust that Subversion will engage press/PR properly and not make
false representations about its incubation status

When typical podlings stay in incubation for a year at a time, that
represents a lot of exposure time. Managing the
brand/incubation-status over that duration is important, so (thus) the
extra controls.

Okay. I *think* that is pretty much the background/rationale (please
refine/add/etc). But that said, we recognize the pain. Are there
*other* ways that we can achieve the same effects without the
double-move? (of lists and repos) Are there avenues of communication
that Incubator can manage? For example, rather than putting in all the mailing lists, can it have a
mandatory header/footer for each message? Can the repository have a
big README.INCUBATION at the root? The Incubator still has control of
all releases, so it still can manage branding on all releases. Can we
tweak ViewVC to dynamically insert a header "This repository area is
part of an Apache Incubator podling". etc etc.


---------- Forwarded message ----------
From: Leo Simons <>
Date: Wed, Nov 11, 2009 at 19:17
Subject: Re: Two other issues to discuss for Subversion

On Tue, Nov 10, 2009 at 7:27 PM, Greg Stein <> wrote:
> There are two other issues to discuss for the Subversion podling:
> * moving the mailing lists directly to
> * placing the source code at /subversion/ rather than /incubator/subversion/
> We are hoping to minimize overall disruption to the community with a
> move to incubator space, then a move to apache space.

I think a good thing we started here is to dig back in memory to find
the core reasons why the process is what it is and make sure we stick
to what's important. I think we have two main reasons to have the
"incubator" name in most those places normally:

1) make clear to users what the status of a project is, i.e. where
incubation is implying that a project may not become an apache project
or that it may not be quite safe legally yet or it may not have a
healthy community behind it or we don't have the trademarks yet or

2) protect the apache brand (you know...if an incubating project goes
up in flames, well, that's ok, we told you that might happen)

3) make it easier to keep a tight leash on PR

I would argue we are not very worried about subversion being "unsafe
for use by the general public" :-).

Similarly, the main thing that would hurt our brand is if the
subversion community would decide to cancel the incubation process
(because apache really sucks, you know...). The most important thing
these days is probably clear messaging on the relevant website(s).

So, as long as y'all make sure to do that good stuff (be clear to
users and protect the involved brands), I think what infrastructure
goes where exactly, can be up to infra@, in this case. And y'all are
talking to PRC anyway about any press stuff. I see no real risks.



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

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

View raw message