(Please don't make me *READ* all the emails :)
On 11/28/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
Folks,
Fact #1: WSCOMMONS-131 is fixed in SVN.
Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is
to do the release this week.
What's the ruckus all about? (Please don't make me all the emails :)
thanks,
dims
[1] http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200611.mbox/[EMAIL
PROTECTED]
On 11/28/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> > On the chat we identified 3 options that we could consider for
> > how to deal with this problem.
> >
> > 1. release what we have
> > 2. release without axis
> > 3. wait until axis is fixed
> >
> > Other options were discussed but did not get much support. For the
> > three that I have listed above (as summarized by Meeraj on the chat),
> > there are some variations and refinements. I have tried to summarize
> > the main points that were made in the chat in the paragraphs below.
> >
> > For option 1, we could mitigate the problem by explaining it in our
> > M2 release documentation, and we could release an update to the
> > Axis2 binding (a mandatory patch) that fixes the problem as soon as
> > new axis2 and axiom releases are available. As long as there is no
> > breaking change to axiom-api before the new release is available,
> > this means at all times we would have a combination that works.
> > The downside is that it looks bad to release something that we know
> > is broken (or will become broken in the future), even though there
> > is a patch available to fix the brokenness.
> >
> I would characterize the downside in different terms, similar to what
> Jeremy has mentioned: we would be putting out a release that
> ultimately will not work. Having a patch doesn't really fix the problem.
>
> That said, it seems we are trying to make a decision without enough
> facts. I propose we find the answers to several questions (or at
> least get more information) before attempting to make a decision on
> the best way of going. How big of an impact are the required changes
> for Axis? And, what is the likely timeframe of these changes, days, a
> week, a month, etc.?
>
> If discover that it is a few weeks then we can step back and ask why
> we are considering a release then patch strategy in the first place.
> There seems to be an assumption that we have to release now as
> opposed to waiting or taking the time to do a proper fix. Why is this
> the case since if someone needs access to the code they can just
> check it out from the repo and build? If it is a convenience for
> applications developers, then having them wait just a little longer
> (they can also just check the code out if they are in a rush) is
> really not that much of a problem given that they should not be using
> Tuscany or SCA for any project that is intended for production.
>
> If we find the fix will require months or an undetermined length of
> time (which does not seem likely), why not refactor for modularity in
> trunk, assess its impact and then decide if we want to move the
> changes to to M2 and cut a modular release that addresses the
> problem? In the meantime, we have the advantage of assessing progress
> on the Axis fix. It may take a couple of weeks to do this but is it
> really critical we get something out this week?
>
> Producing a release that we know is broken seems like we are marching
> to an artificial deadline without enough facts.
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
