Hi,
I've been looking at what we'd need to do for an initial release.
There is an extensive document that provides guidance for incubator
releases here:
http://incubator.apache.org/guides/releasemanagement.html
I think we should discuss why we'd want to do a release in the first
place. The reasons I can think of are:
o The Apache Kato incubator and JSR-326 exist together, having a
release would provide encouragement for people to download
and actually use our materials and perhaps comment on the JSR
early draft review. However, it isn't necessary for there to be an
official release
before there is an Early Draft Review of the JSR.
o In order to graduate as a project we need to have a
community. Having a release would be good to encourage others to
download and
use Kato, and hopefully be not-quite satisfied so as to
contribute to the project. Being able to take patches from someone and
eventually
making them a commiter would be great.
o Considering a release will cause necessitate us evaluating the
current state of the project and establish what is required to move the
project
towards a proper release.
Some of the things we need to consider are:
o Build process - there are certain things we need to produce in a build.
o Documentation - we need some of that.
o Legal - are we clean enough to do a release? Do we know where
everything came from?
o Functionality - do we have enough functionality to be useful?
o Quality - do we have sufficient testing? Is the quality sufficient for
a release?
o Of course, there is the Apache infrastructure to wrangle.
And all of this would be subject to sufficient numbers voting
positively, of course.
As I see it we are:
o Build process - this is a work in progress - Steve is furiously trying
to get maven to meet all our needs.
o Documentation - No question - we need more of this for everything.
o Legal - I don't think we've considered this yet, I don't have a clear
view on this yet.
o Functionality -
* The hprof implementation of the API is mostly there, but it needs
completion.
* The JVMTI python implementation is not considered the final
approach - it needs to be rewritten in C.
* KatoView - is fine, would be good if it was more modular. The
xpath command is a work in progress too.
* JDI Connector - needs more work to be useful with local variables.
o Quality -
* The hprof implementation needs more tests, no question. Plus it's
performance is somewhat lacking still.
* The rest I'm not so sure about.
I'd like to see us in a releasable state. We aren't ready yet though -
I'd like to hear what other people think.
Thanks,
Stuart
Steve Poole wrote:
Hi all, sorry for going quiet!
Stuart and I have been working very hard on getting the kato codebase -
thats API, implementations and demos - in a satisfactory state for
JavaOne.
We've got a lot of stuff done and thanks to Sonals demo of how to use Maven
its now building on Apache hudson from an experimental branch. See here
http://hudson.zones.apache.org/hudson/view/Kato/job/org.apache.kato/ for
latest state. Stuart and I will start to post what there is and how to use
this stuff over the coming days.
The aim of all this work has been to get the project in a state where
everyone involved could see the API in action and check out and build the
code if they wanted. We have all of the code building on Hudson except the
jvmti experimental agent. There will be more changes to come as we tweek
the demos etc for JavaOne but in theory its possible to check out and build
everything now. We'll post howtos on that shortly too.
We are some way off being ready for an initial release of the code but now I
feel that it is actually visible on the horizon.
I'm off to JavaOne where I hope to meet a few of you and connect with other
vendors and just find out how much of what we've been talking about matches
what the general public actually want.
If you've sent me emails or made a post I've missed please ping me again as
its been a very hectic couple of weeks and my inbox is somewhat overflowing!
Cheers
Steve
