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.
----- "Steven Hawkins" <shawkins(a)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
> does not seem helpful. I also understand that Designer feels
> 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
> ----- Original Message -----
> From: "John Doyle" <jdoyle(a)redhat.com>
> To: "Ramesh Reddy" <rareddy(a)redhat.com>
> Cc: "Steven Hawkins" <shawkins(a)redhat.com>,
> teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
> Sent: Thursday, April 23, 2009 7:08:16 AM GMT -06:00 US/Canada
> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
> ----- "Ramesh Reddy" <rareddy(a)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
>>> 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
>> either that they should be tightly dependent on release on each
>> either. It would hard to adjust each others feature bucket, just so
>> they can be released together. Just think about the lost time for
>> 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),
>> you are looking for a stable branch to make such changes. Then it
>> us to either cut a patch or cut another release based on amount of
>> 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
>>> importer changes. I can mock up tests for the connector changes,
>>> I won't really be able to validate a feature until I have two
>>> projects in my hands that are pretty much locked down.
>> I understand, what you are saying, but instead of working around
>> need to fix it. If you saying that we have connector changes that
>> 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
>> further. Lets think in these terms and see if we can reduce this
>> 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
> 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
>> 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
> 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.
> teiid-dev mailing list
Senior Software Engineer
JBoss, a division of Red Hat
teiid-dev mailing list
Principal Software Eng.
Red Hat, Inc.