Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
In-Reply-To: <NBBBJGEAGJAKLIDBKJOPIEBPNLAC.noel@devtech.com>
References: <NBBBJGEAGJAKLIDBKJOPIEBPNLAC.noel@devtech.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B46F254D-0E66-41D4-A1D3-BC2A7FF29765@apache.org>
Content-Transfer-Encoding: 7bit
From: Jeremy Boynes <jboynes@apache.org>
Subject: Re: [WITHDRAWN] Approve release of SCA specification APIs by Tuscany
 project
Date: Fri, 23 Mar 2007 15:55:58 -0700
To: general@incubator.apache.org

On Mar 23, 2007, at 7:34 AM, Noel J. Bergman wrote:

> Jeremy Boynes wrote:
>
>> Dims has asked to see some progress on the Tuscany community front. I
>> have taken these artifacts down for now.
>
> Jeremy, on this and the Tuscany SCA Java kernel, what is your take  
> on the
> effect of the release vis-a-vis community, and on the Tuscany  
> community in
> general?

Dims has a thread on community reconciliation so I'll limit this to  
the effect of these releases.

In r1.0 of the SCA spec there were some significant, incompatible  
changes in the Java APIs compared to the r0.95 version of the spec.  
We have an independent version of the classes for those APIs in the  
project (to my knowledge there is no compiled version available yet  
from the spec group). The community did an extensive review of our  
version against the draft spec and voted to release our version.  
There was some concern over what version number we would assign.

Personally, I think having a version of the APIs from the spec as  
Java code under AL rather than text in a PDF is a very valuable  
resource for the general community. Short of finding a discrepancy  
with the published spec, this is a stable artifact.

For the kernel, we had discussed doing a release of the kernel in  
early Jan and there was general agreement on that[1]. However, there  
were some subsequent changes in the programming models in the spec  
and the implementation needed to be changed to match. That was quite  
disruptive and delayed the release until early March.

Personally, I think having a release available that allows people to  
write components against the revised programming models and then run  
them in Tuscany will encourage them to try it out, give us feedback,  
and offer them an easy way to contribute to the community. I hope  
this leads to more independent developers.

We knew the kernel changes would be disruptive and discussed creating  
a branch to provide a stable base for developing extensions and  
plugins[2]. This didn't work very well, leading to frustration in the  
community.

Shortly after a wiki page appeared to capture requirements[3] which  
initially looked like a product feature/priority matrix (page  
revision 5 for example), followed by a proposal for an alternative  
release in March with different functionality from the release  
already in progress[4]. Shortly after another branch was created to  
support stabilization for that alternative but since then there has  
been no discussion about actually performing a release from it.

Personally, I think the presence of that branch and the substantial  
new development that has gone on there has not acted as a release  
valve but has been very divisive in the community.

--
Jeremy

[1] http://thread.gmane.org/ 
gmane.comp.apache.webservices.tuscany.devel/12250
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13075.html
[3] http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas 
+and+what+folks+are+working+on
[4] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13643.html

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