Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of davanum@gmail.com designates
 209.85.128.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=mvhOgP4yVRY8tj+e0fwoFnkMTF599lj8/cJXB9tBiHMzwAqxMHL805PII9+CZ/4/8K
         kAwCRdXJb+9WYGcOHLKIgeXE2ANCy+8w2w5sKIbL7fXSaEyi7MWxqcT1Nw6Us1vohrB8
         wpfBt3w4ccsnUOSYMlmZHgnqlvbEXad/SLW0s=
Message-ID: <19e0530f0809261559k74ef3308l6c2509e908c01ee9@mail.gmail.com>
Date: Fri, 26 Sep 2008 18:59:40 -0400
From: "Davanum Srinivas" <davanum@gmail.com>
To: general@incubator.apache.org
Subject: Re: Incubator dependencies in Apache projects
In-Reply-To: <48DD58ED.9080000@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <510143ac0809261340q72b13a37q86a28e975efee9f2@mail.gmail.com>
	 <1222462481.25640.52.camel@urgyen> <48DD58ED.9080000@apache.org>

I agree with Doug. We don't need explicit disclaimers. We can
encourage them however to mention it somewhere appropriate.

thanks,
dims

On Fri, Sep 26, 2008 at 5:49 PM, Doug Cutting <cutting@apache.org> wrote:
> Upayavira wrote:
>>
>> Exactly. I was writing something much the same. We could even require
>> TLP projects that have incubating dependencies to include a statement in
>> their releases to that effect: "Should any of our incubating
>> dependencies fail incubation, we (the TLP) will take responsibility for
>> that code so as to continue supporting our users."
>
> -1  Do we require similar disclaimers when we depend on BSD licensed code
> from SourceForge that one guy wrote and that hasn't been updated in a year?
>  Outside of legalities, it's up to each PMC to decide whether a dependency
> is a good for its project.  Sometimes the best solution isn't a great
> solution, but it might be better than no solution at all.  If a project
> depends on something that dies, then it has to decide whether it can live
> without it, reanimate it, use something else, or whatever.  We don't
> otherwise mandate back-compatibility from one release to the next.  Back
> compatibility is a very good way to maintain a community, but it's not
> absolutely required by the ASF.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Davanum Srinivas :: http://davanum.wordpress.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org