cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: [VOTE] Release CXF 2.0-incubator-RC
Date Thu, 26 Apr 2007 14:23:39 GMT


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:dkulp@apache.org] 
> Sent: 26 April 2007 14:41
> To: cxf-dev@incubator.apache.org
> 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 g@i.a.o).    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 g@i.a.o 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:dan@envoisolutions.com]
> > > Sent: 25 April 2007 19:12
> > > To: cxf-dev@incubator.apache.org
> > > 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 <jim@jagunet.com> 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
> > > > >> daniel.kulp@iona.com
> > > > >> 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
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
> 

Mime
View raw message