On Feb 7, 2007, at 10:48 AM, Venkata Krishnan wrote:
Hi,
Heres my opinion from the perspective of some items that I have
owned up to
do quite a while back - support for complex properties and multivalued
properties. I'd see them as some fundamental things that a user might
expect to see out of our next milestone and am happy that they are
a part of
this list that Sebastien has proposed.
I think this is good - there's a lot of value in this feature. But as
far as it being on "Sebastien's list", to be blunt from a community
perspective that's irrelevant. It's on /your/ list of things that are
important and that's what matters.
Now to complete this, I am in dire need for a stable runtime and
client
API. I need this for two reasons i) to figure out the workings of the
kernel through debugging so that I may implement these features
according to
the framework's design (with loaders, builders, etc.) and ii) to
test if the
whole thing sews up together and works as expected. I am just not
able to
figure out how to do this from the current trunk andI have already
started
to plead for help in this regard from the community
I have no complaints about the work that is going on presently in
the kernel
- infact I am excited about the vision with which its being
driven. But
then, I'd be happy if I could do my parts as well alongside.
It's important that we can work together on this and the modules in
the codebase are intended to allow this. The feature you are talking
about seems, to me, to be a kernel feature and as such should be
integrated in and tested with the kernel. The kernel can be build,
tested and debugged without any runtime at all and in terms of kernel
development that is an important aspect to maintain. This feature
should work in every runtime that picks up the kernel and hence
testing should not depend on any runtime.
I hadn't picked up from previous mails that you were looking for help
testing and debugging the kernel - to me they seemed to be about
running application code. Please can you repost them in kernel terms
and let's figure them out.
Here are my thoughts for the path forward...
- I'd like us to plan for the next milestone release ideally by end
of March
to feed the curiosity of our users. Having a long gap will kill their
interest in our technology.
I agree, I think frequent releases are important. That seems to be
inline with what Jim and Ant were proposing (smaller and sooner).
- I'd deem the current kernel work as well as the items listed by
Sebastien
as equally important, but we probably need to figure out how we can
do both
parallely. Can we not do an incremental development of both? For
example
we could baseline a stable and functioning version of the kernel
and runtime
and then choose those items from Sebastien's list that can be
implemented
over this baseline. Or maybe do the viceversa, choose the items
and bring
the kernel up to a level to be able to support its implementation.
Going
forward with both in increments will also help us to merge forward
easily, I
would imagine.
I don't get the issue here. We have several people working in the
kernel at the moment on different features - commits from me,
jmarino, meerajk, rfeng, svkrish in the last 24 hours. This is all
evolutionary development of stuff which will be in the next /kernel/
release.
- I don't think its would be a good idea for the items in
Sebastien's list
to wait until the ongoing work in the kernel and runtime is complete.
I really don't give a flying rat's patootie about what's on a list
developed outside the community.
I think Jeremy's point that we have to stop and now look what we
are doing
as a community is valid. We must have to get things around so that
everybody
in the community is able to contribute effectively.
Those are concrete issues that we can tackle. The pre-spec branch was
meant to provide an environment that would let people develop
extensions whilst the kernel was evolving given we know having
everything merged does not work. If it's not working either, let's do
something different.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
