incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: Publishing api docs for Subversion
Date Mon, 07 Dec 2009 18:40:47 GMT
Branko ─îibej wrote:
> Actually, we're talking about API documentation which in Subversion's
> case is generated from the sources, so yes, it is subject to release
> votes. But only for actual releases.
> Restricting the publishing of generated API documentation would imply
> that we should restrict access to ViewVC, too, because anyone can browse
> that exact same documentation through that, albeit formatted a bit
> differently.

No, that's not required.  The best practice for our official project 
websites is to distinguish content that's intended for the general 
public from content that's intended for developers.  We should only link 
to subversion and nightly builds from the developer portions of our 
sites.  We must, for example, not link to subversion or to nightly 
builds from the release download page.

We have a two-step process for licensing.  First, we try to make sure 
that things are suitable for release before we commit them to 
subversion.  But some things fall through the cracks in this step. 
Sometimes files lack license headers.  Sometimes, especially in the 
incubator, we'll commit something before we have all of the ICLA's on 
file.  Sometimes we commit software that we cannot release and must 
remove.  So as the second step, we review everything prior to release to 
double-check that the licensing is correct.

Between these two steps the content is technically accessible by anyone, 
but our legal claim is that we're not yet distributing it to the general 
public under the Apache license, but only to our developers as a working 
draft.  To support this claim, we only link to pre-release content from 
developer-specific portions of our sites.  ViewVC is a developer tool, 
not a tool we promote for use by the general public.

Posting content intended for release that has not cleared the second 
hurdle bypasses the release process and should be avoided.

We do not have this two-step process for non-released website content. 
Our project home pages are not formally released and we trust that folks 
will be careful about what's posted there.  But we should not use this 
as a grounds to publish content that is otherwise subject to release to 
the general public without a release vote.


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

View raw message