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

[John Doyle]

Yes, the consumers of Teiid need something stable to target, but it doesn't have to be released.

By releasing Teiid before the associated project(s)/systems we only create confusion for the community.  When we release we're all going to post to our blogs, and a couple of months later a press release will happen (who could resist), and drive traffic to go and get the release.  Why set up a system where brand new prospective user who just heard about us for the first time can't come and get version 6.0 of our engine, and 6.0 of our designer, and just assume that they work together?  I understand that patches will happen, and we have to manage that, but why set it up that way?

Please explain to me what is the value of a released 6.0  or 6.1 Teiid if there is no tool that works with it?  
  
I don't question that the Teiid team has been working closely with the Designer team, and I don't question that you have a bear of a schedule for 6.1 and forward.  I just don't see the point on closing the door on a release with no tooling.  Please explain the benefits to me.

~jd 

----- "Steven Hawkins" <shawkins at redhat.com> wrote:

> Everyone here is attempting to build a thriving community.  It's just
> that there are differing opinions about how to do it.  The major issue
> is whether Teiid "releases" should be mothballed prior to Designer
> availability.  So far there is no agreement on that.  Van's assertion
> that Teiid or the Server isn't valuable without a Designer release is
> really is really the same line of thought.
> 
> The Teiid lead's perspective is that we need to have defined Teiid
> releases - in terms of connector api, server api, functionality, etc.
> - so that the Designer, connector, or server developers have something
> stable to target.  To that end a 6.0.0 release of Teiid does not
> impede the 6.0 release of Designer, rather it is essential.  Whether
> it's "usable" on its own only matters to how we promote its use. 
> Furthermore all changes made based upon Designer integration problems
> have been made to both 6.0.1 and 6.1.0.  So we will have the ability
> to provide a release version of Teiid that is completely compatible
> with the Designer near its release.  Finally the Teiid developers have
> been working constantly with the Designer developers to hammer out all
> release issues.
> 
> I should have also been more particular about the phase "forward
> looking".  I mean to say the 7 release will have alternative metadata
> mechanisms.
> 
> ----- Original Message -----
> From: "Van Halbert" <vhalbert at redhat.com>
> To: "John Doyle" <jdoyle 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 8:26:19 AM GMT -06:00 US/Canada
> Central
> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
> 
> 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

-- 
John Doyle
Senior Software Engineer
JBoss, a division of Red Hat
Office: 978.392.3916
Email:  jdoyle at redhat.com