incubator-kato-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: Release Often, Release Early [WAS Re: First Release, tutorial]
Date Thu, 17 Sep 2009 15:52:26 GMT
Hi Robert,


Robert Burrell Donkin wrote:
> On Wed, Sep 16, 2009 at 5:41 PM, Stuart Monteith <stukato@stoo.me.uk> wrote:
>   
>> I notice that there is a thread on general@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/


Mime
View raw message