|Eddie O'Neil||May 25, 2005 10:01 pm|
|Ken Tam||May 27, 2005 11:08 am|
|Noel J. Bergman||May 27, 2005 12:11 pm|
|Eddie O'Neil||May 27, 2005 7:29 pm|
|Eddie ONeil||May 28, 2005 5:23 am|
|Craig McClanahan||May 28, 2005 10:04 am|
|Noel J. Bergman||May 28, 2005 3:04 pm|
|Noel J. Bergman||May 28, 2005 5:57 pm|
|Eddie ONeil||May 28, 2005 8:28 pm|
|Geir Magnusson Jr.||May 29, 2005 6:26 am|
|Eddie ONeil||May 30, 2005 6:29 pm|
|Eddie O'Neil||May 30, 2005 6:35 pm|
|Song Wang||May 31, 2005 6:31 pm|
|Noel J. Bergman||Jun 1, 2005 8:45 pm|
|Eddie ONeil||Jun 1, 2005 9:59 pm|
|Eddie ONeil||Jun 3, 2005 8:30 am|
|Subject:||Re: [vote] beehive v1 milestone 1 release|
|From:||Craig McClanahan (crai...@gmail.com)|
|Date:||May 28, 2005 10:04:35 am|
On 5/28/05, Eddie ONeil <ekon...@gmail.com> wrote:
Putting general@incubator back on the thread.
Noel, Geir, or Craig, can you confirm for everyone that we must pass the JSR 181 TCK before calling a release 1.0-final?
If the release includes code that claims to implement JSR181, then yes it does (just like any other implementation of any other JSR).
If you released the non-JSR components separately, they would not be under any such restriction.
On 5/27/05, Jeremiah Johnson <jerj...@bea.com> wrote:
Note that I narrowed the scope of my opinions to beehive-dev, so if Craig, Noel, etc. are watching from gene...@incubator.apache.org, they may not have seen your comments, Eddie.
-----Original Message----- From: Eddie O'Neil Sent: Friday, May 27, 2005 8:42 PM To: Beehive Developers Subject: Re: [vote] beehive v1 milestone 1 release
One other thing -- if someone (Craig, Noel, Geir, etc) can explain otherwise (that we can go -final without having passed the TCK) definitely let us know.
The sooner we do such a release, the better!
Eddie O'Neil wrote:
It is my understanding after having talked to Craig and others who have been involved in the process of implementing a JSR before that we *can't* do a release of a JSR implementation until the spec is final.
At this point, JSR 181 is not final, and as such, we can't say we're a final implementation of it.
The process of getting the TCK to pass the Beehive WSM implementation is something that we're starting through the appropriate Apache channels.
As far as judging WSM, my understanding is that should be done against the TCK, which means that we need to wait for it to be public before we can pass it.
Jeremiah Johnson wrote:
I am not a committer, so I can't vote. I do have an opinion that I would like to express about the release.
In the 'beehive release status' email from May 19, it said that "we're not able to go for a 'Final' release as the JSR 181 TCK is not yet public". It is unclear when the TCK will be public, so I disagree with the logic of waiting for a final release. It is unclear (to me) if the TCK will even be for the version of JSR 181 that WSM has been implemented against. There is a version of the JSR 181 that has been voted final and Beehive WSM has been coded according to the current status of JSR 181.
In looking at the JSR 181 status, I see that Sun has been 'assured by the spec lead that both [of their concerns] will be address quickly'. At least one of those concerns (full alignment with JAX-RPC 2.0) will probably result in changes to JSR 181 and the TCK. If the TCK isn't available now, then it seems logical to me that the Sun changes will be incorporated into the TCK before the TCK becomes public. (Note that even though I work at BEA - I have no connection to the JSR 181
no idea what the status of the TCK is). The cycles that seem possible to me could just continue to push 1.0 Final.
It seems sensible to me to be voting on going 1.0 and then when the TCK is public and if Beehive can get it, then any incompatibilities should be recorded as bugs. I say 'if Beehive can get it' because it seems that OSS projects in the past have had trouble getting TCKs and I don't know if that will be the case with the JSR 181 TCK or not.
WSM should be judged as best as possible against JSR 181 without the TCK. If WSM is judged to be in line with JSR 181, then go 1.0; if not, then fix it. I think that Beehive should be used as a 1.0 release.
Those are my opinions. Kill me now.
-----Original Message----- From: Eddie O'Neil Sent: Wednesday, May 25, 2005 11:02 PM To: Beehive Developers; gene...@incubator.apache.org Subject: [vote] beehive v1 milestone 1 release
The blocking bugs have been dealt with and we've been adding documentation and samples furiously over the last couple of weeks.
At this point, I'd like to propose that we release a Beehive 1.0 milestone 1. The code is ready to go -- though I believe that a few committers have some outstanding documentation and samples still to be completed.
So, I suggest that we kick the tires of the branch at SVN change 178556 in beehive/branches/v1/m1 (being created now) and let a few
doc / sample related checkins trickle in over the next couple of days. If anyone has concerns about this, please feel free to say so...
Tomorrow (Thursday), nightlies will be cut from this branch so
binary distribution is also available for download.
Given the coming long weekend in the US, this vote will close at 20:00 (8:00PM) GMT on Tuesday, 05/31/2005. Should be plenty of
take the release out to play. :)
I'll start this off with my +1.
Vote: [+1] Yes, the release is ready to go from beehive/branches/v1/m1.  Abstain / not sure. [-1] No, the release is not ready yet. If you vote this way, please provide an explanation why and add what could be done to address your concerns.