incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: incubator releases need to be under www.a.o/dist/incubator
Date Wed, 21 Feb 2007 03:48:04 GMT
On Feb 20, 2007, at 7:11 PM, William A. Rowe, Jr. wrote:

> In other words, we agree there is probably an export issue to resolve,
> however /dist/incubator/ does not exist for a reason, and it would be
> helpful if you ran changes to the incubator past the incubator PMC
> before confusing our podlings with contradictory information.
> Yes - it merits discussion, but what's happened several times with the
> usual push-pull of the discussion here is that half the podlings race
> off to the left while half of them are still on the right, and it
> becomes impossible to manage.

No, what's happened is that the people pointing out the obvious
are usually shouted down by the people who never bother to edit
the documentation.

> FWIW, compare incubating releases to tarballs in tlp.a.o/dev/dist/,
> not those in www.a.o/dist/tlp/ - yes they are not mirrored and
> archived, that's what SVN is for.

Those aren't releases.  See the FAQ.

> The only thing that the BIS is typically interested in is not what
> we ship, but the source code in svn.a.o/repos/asf/incubator/{proj},
> if I've understood the dialogs so far?

No, they are interested in anything identifiable as a product.
Once identified as a product, the next question is whether said
product has been "released", since Release == officially given to
third parties == exported worldwide.

Therefore, the BIS notices (if needed) must be in place before the
Incubator votes on a release.  An Incubator release is no different
from the eyes of the external world (and our legal risk) than any of
the other ASF releases.  The ASF relies on the ability of the Incubator
PMC to make the decision of when to release.  How a release is handled
after that decision is subject to ASF-wide policy.

> ... at least this is how they have been handled.  Part of it is the
> oversight and project health (they haven't graduated yet) and half
> of it is to slow down the "Apache Foo" announcements following some
> code dump.  Once a project proves it can collaboratively develop
> it's code base and create releases (not always as trivial to determine
> as that would sound) then they need to be evicted from the incubator
> to Project status.  Progress, not perfection :)

Yeah, I know, but none of that matters to the BIS.

> Noel J. Bergman wrote:
>> Roy,
>>> At various times, various people have stated various rather
>>> incongruent descriptions of what has to be done when a podling
>>> performs a release
>>> One thing that seems to have been forgotten is that an approved
>>> release must be in the form of SOURCE CODE and must be placed
>>> in the associated PMC's public distribution area under
>>> and by doing so ALL of our releases get archived at
>> The "associated PMC" would be the Incubator, and you might notice  
>> that there
>> is not an incubator/ directory under those locations.

Yep.  In other words: please create one and start using it.

>> As I understand it, the primary issue is that there has been a lot of
>> emphasis to say that Incubator releases are explicitly NOT  
>> official ASF
>> releases and are not to be conflated as such.

Bah!  Doublespeak is not doubleplusgood.  It is an official release
*because* the Incubator PMC voted to release it, and therefore needs
to be processed as a release because that is what the delegated
authority of the board decided when they cast the release votes.

What you call the package, or any color you choose to paint it,
does not matter.  The question regarding "is it a release" is a
simple metric: If the package is delivered outside the context
of the development group with the intent that it will be used
by third parties, then the package is released.  End of story.
Doing that requires official PMC approval, which is the Incubator
vote, followed by the appropriate dropping of artifacts in the
locations that the ASF expects of all releases.

All I am saying is that the last part is not being done right now,
and hence the archives are not being populated with all of the
releases, and therefore the archives cannot be used as the pointer
to the BIS from the exports page to the released versions.
That's bad, for both historical and legal reasons.

>> Were they to be considered
>> official, at least at some points in the past, many ASF folks  
>> would have
>> railed against allowing them at all.  At various points, people  
>> went so far
>> as to suggest that the Incubator be forked separately from ASF  
>> infrastucture
>> to create more distance, which would be going too far IMO.  So we  
>> have made
>> every effort to keep Incubator releases and "real" ASF releases  
>> separate.

Well, tell those people to think about *why* we have these procedures
in place for "real" projects, and then why it should be obvious that
encouraging podlings to avoid those procedures only increases the
risk to the ASF.  If they don't like the perception, then they should
vote -1 on the release (and live with the fact that their perceptions
may be marginally insignificant compared with the majority's desire to
release software before graduation).


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

View raw message