7:08 a.m.
----- "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 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..
7:17 a.m.
New subject: [teiid-designer-dev] Re: 6.1 Release
+1
I've been voting for more "synchronous" releases out of the gate, but not
getting any traction.
We're new to open source, but we've got a unique case here of splitting a product
which does have functional dependencies. I'm all for embracing the whole OS mindset,
but do we gotta be so rigid right out of the box?
Growing pains now matter what, I guess...
Barry
----- Original Message -----
From: "John Doyle" <jdoyle(a)redhat.com>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
Cc: 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 Central
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 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
10:10 a.m.
New subject: [teiid-designer-dev] Re: 6.1 Release
Sure would be nice if the connector could handle its own metadata so
that the importers were not so dependent on the connectors.
IMO, connectors should actually be their own projects and not directly
part of Teiid. In any event, I think your issue is something that many
multi-component projects experience and the simplest answer is a
temporary branch for your changes that can be merged back in post 6.0
tagging.
Furthermore, we should always look at the possibility that component
versions will be mixed and avoid tying versions together. In other
words, the 6.0 version of an importer should probably work in 6.0 and
6.1 even if the connector in 6.1 has changed which probably means that a
6.1 version of the connector probably needs to understand how metadata
was put together in the 6.0 version of the importer. The same goes for
the client JDBC drivers and even the Console.
----
Larry
On Thu, 2009-04-23 at 08:08 -0400, John Doyle wrote:
----- "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 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
5721
days inactive
5721
days old
2 comments
3 participants
participants (3)
-
Barry Lafond -
John Doyle -
Larry O'Leary