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
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
----- Original Message -----
From: "John Doyle" <jdoyle(a)redhat.com>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
Cc: "Steven Hawkins" <shawkins(a)redhat.com>,
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 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
> 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.
teiid-dev mailing list
Senior Software Engineer
JBoss, a division of Red Hat