On Oct 5, 2006, at 7:00 AM, Rick wrote:
Jim Marino wrote:
On Oct 4, 2006, at 10:57 AM, Jeremy Boynes wrote:
I've had two people express concern about the quality level we
currently have: Jim with concern on the unit test coverage, Rick
with concern about quality in general.
Prefacing this by saying that the following only applies to the
Java SCA runtime...
I have a concern with overall quality as well and it extends
beyond code to the things you mentioned below such as samples and
documentation. Poor unit and integration test coverage is an
indicator of the code issues. Lack of documentation is generally
an indication that the doco isn't good ;-)
That said, I think it is important that we have a *milestone*
release. If by "milestone" we mean a distribution which
adventurous runtime extenders can use to test-drive integrating
bindings and component implementation types we may have something
that can be made releasable soon. For me, developers who may be
interested in joining our community are more important than end-
users at this point. I don't think we have anything near good
enough to promote to end-users. Another caveat I would make is
that the runtime extension mechanism will change and we will not
be able to support backward compatibility with what exists today.
I say this since there are proposals under consideration in the
spec group that are as extensive as the recursive model.
This seems a bit counter intuitive to me, or at least I don't
understand it. For me a release is something we say is stable and
you can work with while the project moves ahead.
That's why I said it would be for adventurous extension providers -
it provides them something stable to work with while HEAD evolves.
They will be able to *migrate* their extension, which is a valuable
starting place to me.
So who is this *milestone* release for if not for end users?
If you consider extension writers end-users, then it is for those end-
users. If you consider an end-user someone who writes an application,
we're far from ready IMO.
For those who want to write runtime extensions that will no
longer work in the next release?
Yes ;-)
As an *adventurous* extension writer I'd want to be working now
more than ever on the HEAD knowing that anything I write on this
release is not going to work on the next.
Not really, if things are changing and functionality is not
guaranteed to work at any point in time as typically happens during
early development phases. Sometimes people use the alpha/beta
distinction to denote (among other things) API/SPI stability, with
the former not making any guarantees for it remaining the same. In
our case, what I think we have is pre-alpha due to quality.
Not for end users, and obsolete for runtime extension writers; who
is the audiences we are shooting for?
I'd say our goals in priority order are:
1. To learn how to do a release - the "community thing"
2. To provide a binary that is reasonably stable so extension writers
can begin to experiment with extending the runtime
3. To show progress
I wouldn't say it is obsolete, just that it will likely change and
there will be a migration. That seems useful to me. For example,
Hibernate released early snapshots of EJB3 support and the spec
subsequently introduced significant API changes which forced people
to migrate.
Looking at it a different way, and to use a double negative, we
cannot make the guarantee of no SPI changes given the spec proposals
on the table. Should we wait until the spec is complete? I believe
that would be a mistake.
Jim
For me, having a milestone that meets these general criteria is
important since it shows we have made progress and also to provide
a more stable base for people to work off than HEAD. This will
make our life easier as extensions are further decoupled from
core, since they could work off the milestone until we feel a
stable core snapshot that incorporates any necessary future
changes is ready.
Jim
I'd like to ask everyone's opinion about where we are now, in
general and specifically about the content that we have agreed
will be in the M2 distro. Not just on the code but also on the
samples, documentation, legal etc. that goes with it.
--
Jeremy
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
