incubator-kato-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <>
Subject Re: Release Often, Release Early [WAS Re: First Release, tutorial]
Date Thu, 17 Sep 2009 09:36:52 GMT
On Wed, Sep 16, 2009 at 5:41 PM, Stuart Monteith <> wrote:
> 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.
> Implementations
>   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.

sounds fine for a binary

for apache, the most important release is the source but that's
usually quite easy :-)

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

this is usually the most difficult bit to get right. it's best to
create release candidates early so that the NOTICE and LICENSEs can be
checked for correctness as soon as possible.

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

there's a traditional reluctance to perform release builds on central
machines. at apache, the release manager vouches personally for the
veracity of each release which is difficult unless they control the
environment. i understand why a project with platform specific builds
may want to go down this road but it's best to talk to infrastructure
about it.

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

the SHA1 breakage means that creating strong keys and signatures is a
little fiddly ATM. the apache documentation is in the final testing
stage, just about ready for rollout. please read and follow the
instructions then post any questions or feedback on the community
list. anyone who signs your key needs to update their configuration
(follow the guide linked from

> At some point I'd like to have our release process documented on the
> wiki/website.

it's usually best to make a start on this as soon as possible. i fin

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

a good starting point :-)

- robert

View raw message