Hi Robert,
Robert Burrell Donkin wrote:
On Wed, Sep 16, 2009 at 5:41 PM, Stuart Monteith <stuk...@stoo.me.uk> wrote:
I notice that there is a thread on gene...@incubator.apache.org "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:
API
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
kato.tools.katoview - 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 :-)
I imagine there will be one or two big zips with all of the source.
Shouldn't be a problem.
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.
Sure, we should bear that in mind.
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.
Point taken. Within IBM we have plenty of machines to build all of this
stuff on. We would have trouble building
everything using Apache's infrastructure anyway, because of the Windows
build.
.
o Sign distributables
o Make available as a candidate release (under a home directory on
people.apache.org?)
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
(|www.apache.org/dist/incubator/kato)
|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
http://www.apache.org/dev/release-signing.html 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
http://www.apache.org/dev/release-signing.html).
Thanks for the pointers - it appears that a SHA512 is the recommended
hash now.
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've created a document here:
http://cwiki.apache.org/confluence/display/KATO/Release+Process
As it is something that will be subject to a lot of revision, it's good
that we have the one place for it.
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
Thanks again Robert.
--
Stuart Monteith
http://blog.stoo.me.uk/
