Tuscany Weekly IRC chat log - April 16 2007

[ant elder <an...@gmail.com>]

Here's the log from Monday's IRC chat. Main topics discussed were the up
coming SDO and DAS releases and whether they should be called M3 or if
they're ready to be beta releases.

   ...ant

[11:35] <ant_> hi, are we having a chat today?
[11:36] <lresende> i think so...
[11:36] <ant_> is it now, or has the time chnaged?
[11:37] <jsdelfino> hi
[11:37] <lresende> it's about now :)
[11:38] <lresende> can we start talking about SDO RC ?
[11:39] <lresende> they are still based on artifact version incubator
[11:39] <lresende> and now that we are all going to incubating style, should
they need to respin ?
[11:39] <lresende> the release candidate ?
[11:39] <ant_> is kgoodson here?
[11:39] <kgoodson> hi ant
[11:39] <lresende> that was a question from kgoodson?
[11:40] <ant_> ok, just checking those involved are here
[11:40] <simonnash> what's the user inpact of the mismatch?
[11:40] <ant_> on the chance there's a respin,
[11:41] <ant_> how about the next DAS and SDO release are called something
closer to 1.0 than M3, maybe beta1 or something like that?
[11:42] <ant_> or should atleast for SDO this one go out as M3 and look at
the name later for teh nxt release?
[11:42] <lresende> for SDO, is this going to cause confusion around the spec
version, as they are 2x ?
[11:43] <kgoodson> to be clear,  SDO uses a parent with an incubating
version tag,  but its own ersion s in the release candidate uses incubator
-- i don't think there would be a user impact
[11:43] <kgoodson> id go along with ant_ suggestion that we go to something
alpha-ish next time round
[11:43] <simonnash> if there's no user impact then a respin just for this
does not seem justified
[11:43] <lresende> kgoodson: if you are already using the incubating parent,
we are going to have to release that, right ?
[11:44] <ant_> milestone and alpha names can be a real off putter to get
people to try them
[11:44] <kgoodson> no,  that's my thinking too
[11:44] <kgoodson> my last comment was to somonnash
[11:44] <ant_> didn't we just tell a user on th elist that these are about
production ready?
[11:44] <kgoodson> simonnash
[11:44] <simonnash> we seem to have ahad a few brave souls trying M2 for
both SCA and SDO :-)
[11:45] <simonnash> ok msg received.. thanks
[11:46] <kgoodson> ant_  -- your comment on production ready,  was that
suggestion that beta would be a better tag than alpha -- i could go along
with that for SDO
[11:46] <ant_> yes, thats what i think
[11:46] <kgoodson> sure,  yes,  as i hit return i thought "beta" would have
been a better thing to say
[11:47] <ant_> what needs to get done to make it 1.0?
[11:47] <jsdelfino> +1 SDO is getting really stable now, so beta seems right
to me too
[11:47] <kgoodson> lresende your comment above --- kgoodson: if you are
already using the incubating parent, we are going to have to release that,
right
[11:47] <kgoodson> we already have voted on the 2-incubating parent
[11:48] <simonnash> are we saying beta for this release, or the next time?
i thought kgoodson was saying the next one.
[11:48] <lresende> kgoodson: but jeremy removed the voting thread from the
iPMC, no ?
[11:48] <kgoodson> ah,  i need to look back
[11:49] <ant_> i'd say for this one, but i know that causes a complete
respin and update so fine if thats to much work and we just want to get this
out as M3
[11:49] <simonnash> right, we would have to put that up for IPMC vote
together with the SDO IPMC vote
[11:50] <simonnash> when do we expect the next SDO release?  what is coming
along in SDO's near future?
[11:53] <kgoodson> we have to finish the 2.1 features,  things like
nullable, demand created properties and a couple of other things
[11:53] <kgoodson> right now i am concentrating on making tuscany compliant
against the CTS
[11:54] <ant_> so once the 2.1 features are done would that be ready for a
1.0 tuscany release?
[11:54] <simonnash> sounds like there are opportunities for a beta release
soon... either to finish the 2.1 features or to claim CTS compliance
[11:54] <kgoodson> we havent discussed a next release date for the next
release or content
[11:55] <simonnash> i raised this to see if we could defer beta until next
release.  if the next release is soon that could be OK.
[11:58] <kgoodson> somonnash i'm not sure if you are suggesting deferring
the current release process in favour of stalling until we can have a beta.
My feeling is that we should get out whatever we have now,  whether it be
called M3 or beta,  then follow it up as soon as possible with a rleease
that has all 2.1 features in it
[11:59] <ant_> That seems quite reasonable to me. I was just trying to get
people thinking about the path to beta's and 1.0
[12:00] <simonnash> no i am defnitely not suggesting deferring the current
release
[12:01] <simonnash> the question was abot the naming
[12:01] <simonnash> if it is good to be on something called beta in terms of
attracting user interest, then we would not want to wait a very long time to
have such a release
[12:02] <simonnash> i suppose I would go with M3 for now since we already
have that in the can, then beta for the next one
[12:03] <ant_> How about DAS, is it ready to beta1 for the next release?
[12:03] <kgoodson> ok,  i think the apache way is to release little and
often,  but it would seem sensible to time the next release with having at
least a first cut at implementation of all 2.1 features.  I would hope that
these two criteria would be compatible
[12:05] <lresende> as long as we don't need a specification to be a 1.0, i
think DAS is ok getting beta. But, as it is coupled with SDO, should we
follow the same release naming of SDO ?
[12:06] <simonnash> kgoodson, sounds good.  having a first cut of all the
features seems to match the usual criteria for beta.
[12:07] <halehM> why having all features is a requirement? Another way of
looking at this is having a stable release as release 1
[12:07] <kgoodson> lresende  on the release of the 2-incubating parent pom,
I do recall jeremy closing off one vote thread,  but was it for the parent
pom -- here's a thread that sows the result of ratification of the vote
http://www.mail-archive.com/general@incubator.apache.org/msg12750.html
[12:08] <ant_> lresende, i don't think you need a spec, if its really
coupled to SDO then i guess it makes sense to keep them in sync...but that
just makes me want an SDO beta1 even more :)
[12:11] <simonnash> halehM, i agree that it's not required to have all spec
features for either 1.0 or beta.  But I think it is a normal expectation
that all features intended for 1.0 would show up in 1.0-beta.
[12:12] <ant_> i agree, but it also seems fine to me if you document that
there's one or two specific things missing
[12:12] <simonnash> so if we are targeting a full SDO 2.1 for our SDO
1.0release (which is how I took kgoodson's comment), then beat would
have the
first cut of these features.
[12:13] <lresende> kgoodson: k, i think the parent pom got released,
http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/parent/2-incubating/
[12:13] <simonnash> ant_, yes agreed that if one or twwo things are missing
then that could be documented.
[12:15] <simonnash> i am surprised to see the parent pom there
[12:16] <rfeng> hi, ant_
[12:16] <ant_> hi rfeng,
[12:16] <rfeng> did you see my note on the ML about the build failure
[12:16] <rfeng> ?
[12:16] <ant_> no
[12:16] <rfeng> it seems that we didn't list the ws zones repo
[12:17] <rfeng> and the woden dependency cannot be resolved
[12:17] <simonnash> checking other directories on people.apache.org, there's
something similar in buildtools as well
[12:18] <ant_> ok. i wonder if the binding should even be in the main build
yet, i get intermittent failures running the tests due to TCP ports not
being avaialable, does anyone else see that?
[12:19] <slaws> ant_: i'm now getting databinding problems but the message
always gets to the service
[12:19] <slaws> so far anyhow
[12:19] <jsdelfino> ok, I can move the axis2 databinding module out of the
main build for now, no pb
[12:20] <halehM> New topic.. documentation
[12:20] <halehM> I have pulled together pieces for architecture guide for
SCA Java
[12:20] <ant_> did we close on the SDO and DAS releases? SDO is going to
stay with M3?
[12:21] <halehM> it needs to be reviewed and corrected please. Otherwise,
people will get confused
[12:22] <rfeng> yes, I would like to see all the modules listed/described
and update the diagram to reflect the key pieces
[12:22] <slaws> can we link from the pom description/url element to the page
for that module in the docs?
[12:23] <jsdelfino> sounds like a good idea, what is maven going to do with
the url?
[12:23] <kgoodson> ant_ i think i understood we were ok to stay with SDO  M3
and follow up with a beta release asap after with a first curt of all
2.1features that are currently missing
[12:23] <slaws> not sure - haven;t tried it yet - will give it a go
[12:24] <slaws> and post
[12:26] <kgoodson> simonnash -- previous-topic-aside:  this is the set of
artifacts I recall being withdrawn (SCA Spec APIs)
http://www.mail-archive.com/general@incubator.apache.org/msg13176.html
[12:33] <simonnash> kgoodson, you are correct.  was there a previous IPMC
vote on the pom and buildtools?
[12:33] <kgoodson> yes
[12:33] <simonnash> sorry for getting confused
[12:34] <kgoodson> np
[12:34] <lresende> simonnash: i think the parent pom got released,
http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/parent/2-incubating/
[12:35] <simonnash> yes, I saw the released artifacts.  i was not sure about
the IPMC vote... now confirmed.
[12:47] <ant_> I'm going to have to drop offline shortly, is there anything
else to chat about?
[12:49] <jsdelfino> I'd like to restart a discussion on our next SCA release
some time this week, we can do that on the dev list...
[12:50] <ant_> sounds good
[12:50] <ant_> BFN then. thanks everyone. I'll post a log to the ML