[teiid-designer-dev] Re: [teiid-dev] 6.1 Release

[Van Halbert]

Plain and simple, the server is no good without the designer.    And  
until we can get thru this period of getting it all to work together  
as a stable set of code, it doesn't do anyone any good.   I agree,  
down the road, once we get this working that the 2 projects can live  
independently, but it can't happen until its all working.    And the  
community doesn't start thriving until they can use it.

On Apr 23, 2009, at 8:16 AM, John Doyle wrote:

> I addressed the desire to have additional mechanisms to create Teiid  
> artifacts, and those mechanisms don't exist yet, we shouldn't  
> operate like they do.
>
> Its our job to build a thriving community, and the success of that  
> effort will be determined by our ability to produce compelling high  
> quality community projects, not platforms.  The platform is  
> immaterial to this discussion.
>
> ~jd
>
>
> ----- "Steven Hawkins" <shawkins at redhat.com> wrote:
>
>> We understand your perspective, but forward looking we do not see the
>> Designer as being the only metadata mechanism for Teiid.
>> Intrinsically tying the release schedules together even from the  
>> start
>> does not seem helpful.  I also understand that Designer feels  
>> pressure
>> to release - however there is no hard requirement to do so.
>>
>> As Ramesh indicates it is already the role of the platform release to
>> put the stamp of quality across all correlated projects in that
>> platform.  We do not need to reproduce that effort in the community -
>> it will already flow into the upstream.
>>
>> Also we will have a 6.1.0 release in the unstable spot starting next
>> week.
>>
>> ----- Original Message -----
>> From: "John Doyle" <jdoyle at redhat.com>
>> To: "Ramesh Reddy" <rareddy at redhat.com>
>> Cc: "Steven Hawkins" <shawkins at redhat.com>,
>> teiid-designer-dev at lists.jboss.org, teiid-dev at lists.jboss.org
>> Sent: Thursday, April 23, 2009 7:08:16 AM GMT -06:00 US/Canada
>> Central
>> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
>>
>>
>> ----- "Ramesh Reddy" <rareddy at redhat.com> wrote:
>>
>>> On Wed, 2009-04-22 at 20:58 -0400, John Doyle wrote:
>>>>
>>>> I'm aware that there's an aggressive schedule, but I question
>> that
>>>> value of releasing Teiid on it's projected release date, if the
>>>> Designer is not ready to release, or vice versa.
>>>
>>> Release soon and release often is the mantra for JBoss. I do not
>>> believe
>>> either that they should be tightly dependent on release on each
>> other
>>> either. It would hard to adjust each others feature bucket, just so
>>> that
>>> they can be released together. Just think about the lost time for
>> the
>>> team waiting.
>>
>> What about leaving it on the shelf until they're both done?  There's
>> no lost time if one project completes it's 6.1 work but it's not
>> 'officially' released and labeled as 6.1 until the other project is
>> ready.  We already have stable and unstable slots on the community
>> site, but we're not putting any unstable out there. Put it out there
>> as unstable and move onto features for the next release.  When we've
>> reach a level of quality between the two projects, then we label it
>> and post the stable version.
>>
>>>
>>> For this exact purpose we are creating branch (for example 6.0.x),
>> if
>>> you are looking for a stable branch to make such changes. Then it
>> is
>>> up
>>> us to either cut a patch or cut another release based on amount of
>>> changes.
>>>
>>> Platform releases, that tie all of them together.
>>>
>>
>> Why do we want to have a process that lends itself to the possibility
>> that we will have to patch a release just so users can have tooling
>> that works with it?
>>
>>>> I have changes coming in 6.1 to connectors that are depending
>> upon
>>>> importer changes.  I can mock up tests for the connector changes,
>>> but
>>>> I won't really be able to validate a feature until I have two
>>> stable
>>>> projects in my hands that are pretty much locked down.
>>>>
>>> I understand, what you are saying, but instead of working around
>> it,
>>> we
>>> need to fix it. If you saying that we have connector changes that
>> are
>>> dependent upon tooling code to the runtime code, I we need to
>>>
>>> a) better plan according to upcoming releases
>>> b) decouple dependencies,  use better abstractions
>>> c) modularize
>>>
>>> on these fronts we have stepped up and we need to to continue to
>> push
>>> further. Lets think in these terms and see if we can reduce this
>> for
>>> future releases. Can XML importer plugin can be deployed on its own
>>> without Designer stuff?
>>
>> All of these things are great, and I agree with all of these things.
>> To go further, we have wanted and and even produced alternative
>> tooling (mmshell).  Someday there may be several different options  
>> for
>> creating the artifacts that Teiid needs, and then your argument
>> becomes much stronger.   But I don't think the projects should  
>> adopt a
>> process that treats the the individual projects as independent when
>> they aren't yet.  We should operate in the circumstances that exist,
>> not the ones we hope to create.
>>
>>>
>>>> We can call them independent all we want, users will disagree.
>>>> There's already traffic on the lists to demonstrate that.
>>>>
>>> The current release we are going through lot of connector type
>>> definition changes, once we stabilize embedded integration and
>>> connector
>>> integration this should reduced greatly, unless we change the vdb
>>> indexing. We got JIRAs for lot of these already.
>>
>> Yes, should, but how will we know?  How do we validate that?  The
>> truth is that we don't know what we're going to be changing in 18
>> months, and maybe it's going to be disruptive, maybe it's not.  I  
>> tend
>> to think that if it's not, then we're probably not doing very
>> interesting work.  Another uncomfortable truth is that it's very hard
>> to see the full consequences of the changes we make.  But either way
>> we should adopt a process that leads to higher quality, and I think
>> that posting the projects as unstable until we validate compatibility
>> achieves that without negative effect.
>>>
>>> Ramesh..
>>
>> _______________________________________________
>> teiid-dev mailing list
>> teiid-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/teiid-dev
>
> -- 
> John Doyle
> Senior Software Engineer
> JBoss, a division of Red Hat
> Office: 978.392.3916
> Email:  jdoyle at redhat.com
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev

Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert at redhat.com