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

[John Doyle]

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