incubator-kato-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: Release Often, Release Early [WAS Re: First Release, tutorial]
Date Wed, 16 Sep 2009 16:41:39 GMT
I notice that there is a thread on "Help 
reviewing PhotArk podling release", which is quite educational for what 
we should expect
for a release.

I'd assert that our release should consist of the following items:

    kato.api - The API interfaces and the services framework
    The JSR-326 specification.
    TCK - harness and tests.

    kato.cjvmti - The JSR-326 API JVMTI implementation
    kato.native.cjvmti - The JVMTI agent.
    kato.hprof  - The implementation of JSR-326 API for hprof.

Tech demos:
    kato.jdi - The JDI connector - The command line tool.

Eclipse tech demos:
    kato.explorer - The API explorer for Eclipse
    kato.hexeditor - the hexeditor
    kato.rtexplorer - the java runtime explorer.
    JDI connector eclipse plugin.

There are other packages, but these are dependencies for above and not 
useful in their own right.

Perhaps our release would consist of all of these items, with each 
category being a separate distributable. We'll
need to decide on their names at some point. I suggest the prefix we use 
is "apache-kato-incubating-*".

To achieve this we will have to:

 o Assess the state of what we have and fix it up where necessary.
 o Create LICENSE and NOTICE files, where necessary.
 o Get the jobs building on Apache's Hudson server (except for where 
that is not possible, e.g. Windows builds).
 o Write documentation for it all. Shouldn't be too onerous.
 o Create a job on Hudson that will package all of the other builds, in 
the process:
    o generating checksums
    o Incorporate licenses and notices
    o generate source and binary distributables.
 o Sign distributables
 o Make available as a candidate release (under a home directory on
 o Call a vote on kato-dev mailing list.
 o Formally ask the Incubator PMC permission to do a release
o Repeat and revise previous steps until acceptable.
o Put distributions in appropriate place 
|o Modify website to include "downloads" page with links to current release.
o Announce the release to the world.

We'll need a release manager - I would like to do that if nobody has any 
objections (+1's will be graciously accepted).
I should be able to get a key signed by some Apache folks in IBM Hursley 
for signing the distributions.
(i.e. for the web of trust, and to establish that I'm not actually 
BlueGene/Stoo )

At some point I'd like to have our release process documented on the 

I'd vote for a "milestone" release, that adequately descibes what we're 
trying to achieve.

There are lots of other details to resolve, but how does all of that look?


Robert Burrell Donkin wrote:
> On Tue, Sep 15, 2009 at 4:59 PM, Stuart Monteith <> wrote:
> <snip>
> >-8  Snip
> IIRC apache harmony uses milestones. might be worth taking a look at
> how they do it...
> - robert

Stuart Monteith

View raw message