Hi Venkat,
Thanks for the write-up, comments inline.
Jim
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.
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.)
Debugging and understanding the kernel architecture should be
orthogonal to a stable "runtime" and client API. Otherwise, we have
failed with our architecture design. The kernel architecture should
not be dependent on either the runtime (e.g. how it is embedded) or
the client API.
For example, you should be able to debug various subsystems through
the existing testcases. These, coupled with the posts to the mailing
list describing some of the new work being done, should provide you
with a starting point. Of course, documentation and write-up could
always be better...If you are still having trouble after working
through the testcases, I'm sure people working in particular areas of
concern would be happy to answer any questions you pose.
In terms of the specific work you are interested in, e.g. complex
properties, you should be able to go ahead and work off kernel
without issue. I would follow-up with Meeraj and Jeremy on the loader
side to sync with what they are doing.
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 believe Jeremy responded in his launcher post. If not could you
send specifics to the list and someone will try and help out? We need
to update the Maven iTest plugin. I don't think you need to wait for
this, however, to start any of the work you are interested in.
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.
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.
Agreed that a long gap will kill momentum. That's why I suggested a
compact kernel release back in January, and that's what several of us
are working towards. I think it would be great to have additional
features others may be interested in. What I'm not too keen on is
holding up the kernel release for extensions - that will put us back
in the position we are attempting to get out of with the modularity
work.
That said, having a follow-on release that uses a prior-released
kernel version sounds like a great idea.
- 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?
Don't we get that with modularizing the build as we have done?
Extensions work off a release or snapshot of kernel that evolves over
time. I'm not sure why work on kernel cannot be done in parallel
assuming people coordinate on list.
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.
I don't think this is appropriate or really needed. All development
should be done against trunk. Extensions may chose not to use kernel
directly, in which case they can point to a snapshot.
Or maybe do the viceversa, choose the items and bring
the kernel up to a level to be able to support its implementation.
I'm not sure I follow this. If we need the kernel to support certain
features, I'm happy to help out as best I can. However, I'm really
not for participating in another release that repeats the M1 process
where we concocted a long list of "requirements" that people marched
to and took months to deliver. I'd rather have smaller, incremental
releases. If people want to have a release that follows this longer
process, they should do so as long as we can release kernel in
accordance with the "release early, release often" mantra.
Going
forward with both in increments will also help us to merge forward
easily, I
would imagine.
If development is not done against the trunk I think this will be
very problematic both from a technical as well as a community
perspective. We need to work together, not separately. If during the
release process we need to branch for stability with the intention
that only bug fixing is done in branch, that works for me. However,
development would be done against trunk.
- 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.
Why? :-) I think that work should start now in kernel against trunk.
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.
+1. For me, doing development in trunk and relating a release
proposal to work already being done is a first step toward getting
people to act more like a community.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
