On Jul 19, 2006, at 2:07 AM, Simon Nash wrote:

I wasn't asking for an "official" policy statement on this, and
I wasn't suggesting that we stop all innovation and move into a
phase where we only work on things that were part of M1.

By releasing M1, we moved from a phase of focusing purely on
the developer community into a phase of starting to attract
potential users as well.  I think we need to strike a balance
between the needs of developers and users.  We met some
potential users at ApacheCon, and I expect that we will meet
more at OSCON.  For now we can point them to M1, but given
our desire to focus around a single codebase that is actively
being enhanced, I would expect that we would want to be able to
start to point these people to the new codebase in the fairly
near future.

And we should. In fact, I would point them at the "new" code now, not just in the future. That is the codebase chosen by the community. That is our code.

If you believe the decision to adopt chianti as our code to be in error, you are free to ask the community to reconsider, although I believe the vote last week accurately expressed the community will (as willful an act as it may have been ;-) ).

Of course, people can also resort to M1 if they prefer to experiment with the .9 version of the SCA specification or features specific to that milestone.


Even from a developer community standpoint, I think there is
considerable value in maintaining a working base level of
functionality that can support end-to-end scenarios.  This
allows developers creating new code to exercise that code in
the context of real-world usage, in addition to unit tests.


I would imagine there is unanimous agreement on this point as we are working hard to add "real-world" functionality that interests members of the community.

Based on your statements, it sounds as if there is functionality you would like to see added. The somewhat, although not completely, flippant response to this is: Thanks for volunteering!

If you would like to see a particular set of functionality in Tuscany you can either request it (preferably in JIRA) or develop it and submit a patch. Depending on the importance of the feature to the community, I suspect the latter approach has a higher probability of success in the short-term. It is also the option I would personally prefer as it expands the active, contributing segment of the community.

Jim

Simon

Kenneth Tam wrote:

-0 on ordaining some kind of "official" priority for functional
equivalency with M1 -- my opinion is that at this stage in the project
(ie, incubation), developer community is significantly more important
than user community.  I'd rather we take a more free form stance with
respect to encouraging development in areas people find compelling
(including of course, the porting of functionality from M1).
On 7/18/06, Simon Nash <[EMAIL PROTECTED]> wrote:
It is true that users who just want a working binary download
have the M1 release to work with.  However, the Tuscany community
itself will benefit from being able to run end to end scenarios
to exercise code that they contribute to the new trunk.  So if we
do make this switch now, I believe that we need to focus as a
community on getting the new trunk into a state where it can run
end to end scenarios with comparable functionality to what we had
previously in M1.  I'd feel more comfortable if I saw comments on
this list agreeing that this should be the priority immediately
following the switch.

   Simon

Rick wrote:

> For me the vote said it all; its good to go to switch. I think I can > understand your position and probably would side with you if it wasn't > for two things: We have a release so users just wanting to understand > SCA and the basics of Tuscany have something stable to work with. Also > this is just a switch, the head of the trunk should be preserved in a > branch. Just before the switch I would recommend both have tags too.
> Doing this doesn't stop any discussion, it doesn't stop bringing
> function/code from the current head back in to Chianti; it even doesn't
> prevent in the case community decides we prefer to switch back.
>
> Simon Nash wrote:
>
>> Jeremy,
>> Before you do this, I'd prefer to see some discussion about the
>> functional differences between chianti and the current trunk code
>> and how we would see these being addressed, as I said in my
>> previous email on this subject.  What do you (or others) think
>> about this?
>>
>>   Simon
>>
>> Jeremy Boynes wrote:
>>
>>> With the vote in favour of switching, I am about to start moving
>>> chianti into trunk. I will move the current sca parts into a branch >>> (branches/pre-chianti) and move the chianti code into trunk. I will
>>> make the version in the poms 1.0-SNAPSHOT like the SDO tree.
>>>
>>> I expect to complete this tomorrow or possibly Wed if there are
>>> build issues. If anyone has a bunch of uncommitted changes or a big >>> patch for submission please speak up soon to avoid merge issues.
>>>
>>> Thanks
>>> --
>>> Jeremy
>>>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to