----- Original Message ----
> From: Bertrand Delacretaz <[email protected]>
> To: [email protected]
> Sent: Wed, December 1, 2010 2:18:50 PM
> Subject: Re: Basing Apache releases on releases from incubating projects
>
> Hi Chris,
>
> On Wed, Dec 1, 2010 at 7:42 PM, Mattmann, Chris A (388J)
> <[email protected]> wrote:
> > Hey Joe,
> >
> > I agree with pretty much everything you said below. One good thing (and
>correct me if I'm wrong) but is that I interpret what you are saying here:
> >
> >> This is not an academic question. Ask Dims how things worked for
> >> Geronimo when they had such a dependency. Basically the expectation
> >> is that the dependent project will check the code into their own tree
> >> and finish whatever vetting needs to take place. It then becomes a part
> >> of *their* release process, not treated as an external dependency (how
> >> they bundle that software doesn't really matter).
> >
> > to mean that it's the decision of the project who is including
> > the dependency's source code in their own source code (and that
> > is a mechanism to achieve what I'm proposing). If that's what you
> > are saying then I agree...
>
> FWIW I agree with this - if a project includes unreleased code from
> another ASF project in their release, they take responsibility for
> that.
It's all the same org, so I don't see how "they" can take responsibility
for anything. The whole point of the corporation is to shield people from
liability, not to expose volunteers for taking on responsibility for code they
aren't chartered to be developing and distributing.
Releasing legally-vetted code is an organizational requirement, and a
project's svn trunk is in a constant state of flux. Releases are the
only distribution points we have that we are reasonably certain about
their legal status. It should be up to each project to determine what
and when it's appropriate to have their code released. If a project
isn't performing releases as fast as you'd like, get involved in their
community and help them release it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
