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(a)redhat.com&gt; 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(a)redhat.com&gt; > To: "Ramesh Reddy" <rareddy(a)redhat.com&gt; > Cc: "Steven Hawkins" <shawkins(a)redhat.com&gt;, > 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&gt; 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 -- John Doyle Senior Software Engineer JBoss, a division of Red Hat Office: 978.392.3916 Email: jdoyle(a)redhat.com _______________________________________________ teiid-dev mailing list teiid-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-dev