Re: General Update - initial release

[Stuart Monteith <st...@stoo.me.uk>]

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
>
>   

Re: General Update - initial release

[Stuart Monteith <st...@stoo.me.uk>]

Hi All,
    I was wondering what people thought needed to be done for the Early 
Draft Review of the JSR.

The issues I'd particularly like some comment on are:

    o Do you believe we have satisfactory infrastructure for peoples 
comments to be made easily. I refer to, of course, here: 
http://cwiki.apache.org/KATO/javadoc-comments.html
    o What degree of satisfaction is there with the API? Just now we 
have no objective measure of how far off the API is from where everyone 
wants it to be.
    o If people are unsure as to how well the API meets their 
requirements, what can be done to assist it's evaluation?

I look forward to your comments,

    Stuart


Stuart Monteith wrote:
> 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
>>
>>