Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=2vY0eq+CD8MUx4r/yA94NqBYgbgFjd12KzytzsPup/+tSfuhv5NxljZtfDRbtarFN4WUKAdFFWf9FUvDG/GgIMBM9UBpoULYYLsL6Uh24PI5Ved9Wj429XUUbbwlwePutKg5IEzL9rvAMjw3FxRb2pBJyRBubWSTgGW1Vzq/ynU=
  ;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <78E7724A-D853-42C7-8410-FE02B80B9C0E@gmail.com>
References: <78E7724A-D853-42C7-8410-FE02B80B9C0E@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <347B5992-629F-4609-81E5-3CDCD2062D42@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: 2.0 release status
Date: Mon, 6 Aug 2007 08:25:05 -0700
To: dev@geronimo.apache.org


On Aug 6, 2007, at 6:16 AM, Kevan Miller wrote:

> Here's where things stand at the moment
>
> Specs
> We have a vote on 3 spec releases that have been held up by a CDDL  
> licensing issue. After reviewing the issues, I don't think these  
> specs have a problem. They are not built with CDDL licensed  
> materials. We <could> start to rebase our specs on CDDL licensed  
> materials. I think this would make things cleaner. However, I don't  
> think that it is necessary to do that now.

It would also make it so we couldn't release them according to  the  
draft 3rd party licensing policy at http://people.apache.org/~cliffs/ 
3party.html which prohibits cddl source code in apache releases  
("Categoy B).  Sam has indicated that xsds are source code in his  
opinion and I certainly agree.

>
> Schemas
> We have an outstanding vote on two schema releases. These releases  
> are built from CDDL licensed materials.
I believe the copies under vote are NOT built from CDDL but from the  
previous non-cddl xsds.  I guess only Prasad knows for sure.

> At the moment, the license and notice files for the schema releases  
> are not correct.
I think they are correct , since the jars are not built from cddl  
sources.  In any case I think that (in disagreement to Craig Russell)  
that even if we started with CDDL schemas the xmlbeans generated  
source and binary would be under asf, not cddl.  If not, then the  
xmlbeans code we've been using generated from the pre-cddl schemas  
would be under the mysterious sun license that prohibits all use, so  
we wouldn't be able to write a javaee server in the first place.

> I think we should do the following: move the schema source  
> directories from our tck svn repository to our public repository,  
> fix our license and notice files, and build schema releases from  
> there. Note that both the schema source directories and the  
> resultant schema binaries will have CDDL licensed elements. The  
> current guidance that we have received from legal-discuss is that  
> both source and binary CDDL is ok for us to release. We will need  
> to be sure that our schemas follow all CDDL requirements.

I don't think we should do this until the violent disagreement  
between the 3rd party licensing policy and sam's suggestion that it's  
ok to use the cddl xsds is resolved.

thanks
david jencks

>
> TX-Manager and Connector components
> The recently released 2.0 version of geronimo-connector has a  
> problem. The geronimo-connector-2.0-tests.jar does not contain any  
> classes. So, server builds fail when running tests. Matt has  
> created a 2.0.1 release. We'll need to vote on this new release.
>
> 2.0 Release
> Matt and I have been working on updating branches/2.0.0 in  
> preparation for a release. At the moment, the build is failing  
> because of an xmlbeans version incompatibility. I haven't worked  
> out the cause of this problem, yet. Once we're able to build, we  
> can start testing and get a release vote started. This vote either  
> cover the above specs/schemas/components releases or the vote would  
> be dependent on separate release votes.
>
> --kevan