Balancing is hard... it's what makes pure open source
in some ways more "difficult" than commercial proprietary
s/w. Open Source should not have "schedules"... the code
is ready when it is ready. Forced timetables should be
avoided.
With all that said, one also needs to recall that you have
a user (and developer) community to handle as well...
It does not serve Yoko (or anyone) to "rush" CXF just
so "they have something", but neither can you ignore
that either... A Release Candidate should mean just
that: it's a potential release. If it isn't, then
don't call it that, or don't release it yet.
On Apr 26, 2007, at 10:23 AM, Glynn, Eoghan wrote:
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 ...
