I have no desire to kill you after reading this email. :)
I really want us to get 1.0 Final out the door, and I believe that the
Controls and NetUI pieces are ready for it now. It's even possible that
WSM is ready despite not having access to a TCK that it can pass, but I
think that going Final without this key piece would meet with
resistance. I would push for doing just that, but only if it becomes
clear that we'll have trouble getting the TCK, and I think that is not
clear currently. To me it's a matter of timescale -- even though the
Controls and NetUI pieces are ready for prime time, I don't think it
hurts to wait for WSM unless the waiting is indefinite.
If the TCK timeframe turns out to be relatively short, then all of
Beehive will benefit from a bit of additional polish in the meantime,
plus a seal of approval on WSM.
My 2c.
Rich
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 spec and
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.
- jeremiah
-----Original Message-----
From: Eddie O'Neil
Sent: Wednesday, May 25, 2005 11:02 PM
To: Beehive Developers; [email protected]
Subject: [vote] beehive v1 milestone 1 release
All--
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
more
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 that
a
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 time
to
take the release out to play. :)
I'll start this off with my +1.
Eddie
=====
Vote:
[+1] Yes, the release is ready to go from beehive/branches/v1/m1.
[0] 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.
