Sure we all want to get the release out ASAP.
We also all obviously want the release to be the highest quality possible. So we've got to strike a balance, in terms of weighing up the known issues versus the pressures for a quick release. I'm not being argumentative, or trying to slow down the release, just requesting that we make an explicit trade-off between releasing with known issues and taking the time to fix these. I'm not talking weeks or months here. For example, if was to take a couple days to clean up the Spring createdFromAPI versus suffix inconsistency, then I think this would be worth doing. IMO our plethora of config options is already confusing enough without users having to contend with this inconsistency also. Just my 2 euro-cents ... Cheers, Eoghan > -----Original Message----- > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > Sent: 26 April 2007 14:41 > To: [email protected] > Subject: Re: [VOTE] Release CXF 2.0-incubator-RC > > > Eoghan, > > On Thursday 26 April 2007 06:26, Glynn, Eoghan wrote: > > Can you be explicit on the much more we'd have to lose by > holding the > > release until the outstanding issues are resolved? > > Very simple: we've already pissed off some of our users by > waiting this > long. We NEED to get release artifacts into the maven > repository ASAP > so other projects can proceed with their releases. > > The main example is Yoko. 2 months ago, they asked for a > release so they > could do a release. We were unable to provide that to them. They > ended up doing an "orb only" release that didn't include any > CXF stuff > at all. That is/was a major "lose" for our community as > well as their > community. > > They have again asked us for release artifacts. If we > cannot provide > them, they will again be forced into an "orb only" release. > That is > BAD for both projects. We need to be in a position to > respond to such > requests and help our users. Not force them into dropping CXF stuff > from their releases. > > I don't know the current Yoko plans, but at one point they wanted a > release by JavaOne. Let's look at the timeline. To do that, they > need to call their vote by next Tuesday. (3 days vote > internal, 3 days > on [EMAIL PROTECTED]). Thus, our release needs to be done before that. > The > current vote will hopefully be done tomorrow afternoon internally at > which point I can start the [EMAIL PROTECTED] vote. 3 days later is Monday, > although due to the weekend, I should give it longer. We're already > cutting it too close. > > > > All other things being equal, it would seem more logical to > me to just > > fix up the issues. > > Yes, we need to fix the issues. I'm hoping to be able to get on a > fairly frequent release cycle. I'm actually hoping for every 4-6 > weeks. That should provide recent artifacts in the release > repository for other projects to depend on/use. If we follow > that schedule, it > also allows users to expect and plan on when the next release > will be. > It's been almost 5 months since the last release. That's > WAY too long. > > We should not force our users to depend on SNAPSHOT versions for very > long. That's a recipe for disaster. We need frequent non-snapshots > that the users can migrate to as their plans and schedules permit. > > > > Could we get the best of both worlds by inviting feedback > on a release > > candidate, as opposed to a full release? > > Doesn't solve the Yoko problem. > > > In anycase, to meet our diversity requirements and attract > new users and > developers, we need to get code out to them. This is the > first step > in that process. > > > Dan > > > > On specific issues, I'd like to see the Spring bean > > createFromAPI/suffix made consistent before the release, as > this is a > > user-facing issue that will cause confusion and would be harder to > > change (yet again) further down the line, when hopefully > there'll be a > > lot of users with config files in production. > > > > Cheers, > > Eoghan > > > > > -----Original Message----- > > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > > > Sent: 25 April 2007 19:12 > > > To: [email protected] > > > Subject: Re: [VOTE] Release CXF 2.0-incubator-RC > > > > > > I think we can update the STATUS/DISCLAIMER issues for our 2.0 > > > final. > > > > > > I'm expecting that we still need to squash some bugs in > this release > > > - including things turned up by the TCK, 2 or 3 examples > (although > > > from what I understand they mostly work, just not with > servlets?), > > > and a few policy things. I think we have much more to > lose though by > > > not doing a release ASAP and not getting feedback then we do by > > > waiting until all these things are resolved > > > > > > Cheers, > > > - Dan > > > > > > On 4/25/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > > +1 on the release by the way :) :) > > > > > > > > On Apr 25, 2007, at 10:55 AM, Jim Jagielski wrote: > > > > > Looking over the distro-src: > > > > > DISCLAIMER seems to lack newlines... > > > > > STATUS is very out of date > > > > > Build and test looks good (cannot recreate > > > > > the exceptions Jim Ma sees) > > > > > > > > > > In the binary distro: > > > > > Same DISCLAIMER note > > > > > Again, build and test looks good. > > > > > > > > > > On Apr 24, 2007, at 2:50 PM, Daniel Kulp wrote: > > > > >> This is a vote to release CXF 2.0-incubator-RC. This > > > > > > release is a > > > > > > > >> major step forward from M1. This release includes > following new > > > > >> features and enhancement: > > > > >> * WS-policy framework > > > > >> * WS-Security > > > > >> * HTTP transport enhancements > > > > >> * Aegis databinding support > > > > >> * Configuration refactoring and improvement, > > > > > > including support of > > > > > > > >> Spring 2.0 config syntax > > > > >> * Tooling (mainly wsdl2java, java2wsdl) refactoring and > > > > >> improvements > > > > >> * Many JAX-WS issues fixes (still not tck compliant yet) > > > > >> * Many other JIRA issues and code cleanup > > > > >> * MUCH MUCH more > > > > >> > > > > >> > > > > >> The staging area is at: > > > > >> > http://people.apache.org/~dkulp/stage_cxf/2.0_incubator-RC_take > > > > >>1/ > > > > >> > > > > >> The distros are in the "distro" directory. > > > > >> The "maven" directory contains the stuff that will by > > > > > > pushed to the > > > > > > > >> m2-incubating-repository. > > > > >> > > > > >> This release is tagged at: > > > > >> http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0- > > > > >> incubator-RC/ > > > > >> > > > > >> > > > > >> Here is my +1. The vote will be open here for 72 hours. > > > > >> > > > > >> -- > > > > >> J. Daniel Kulp > > > > >> Principal Engineer > > > > >> IONA > > > > >> P: 781-902-8727 C: 508-380-7194 > > > > >> [EMAIL PROTECTED] > > > > >> http://www.dankulp.com/blog > > > > > > -- > > > Dan Diephouse > > > Envoi Solutions > > > http://envoisolutions.com | http://netzooid.com/blog > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] > http://www.dankulp.com/blog >
