cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: what are required for contributing to release management
Date Thu, 28 Sep 2006 17:41:17 GMT

On 27 Sep 06, at 12:30 PM 27 Sep 06, Bozhong Lin wrote:

> Hi,
> As I previously posted email on cxf-dev, I am very keen in  
> contributing to CeltiXfire release management and other project  
> management related stuff. From the Apache release process document  
> [1], I am not sure what qualification/requirements it takes to get  
> the release management job done:
> 1. Does it require SVN commit right? I don't have CXF commit right  
> yet (working toward it :-), would this be a problem?

Yes, you need commit privs as you create a new tag and modify trunk.

> 2. Does it require some one to be on PPMC?

Yes, generally.

> 3. Signing release. According to my knowledge, ASF needs to meet in- 
> person whoever will be signing release. I am willing to make the  
> trip meet ASF person in US.

It's not mandatory that your key be signed by another ASF person but  
it's recommended. Anyone in the web of trust will do so you probably  
don't need to travel all the way to the US.

> I hope I can contribute to CeltiXfire release management without  
> commit access and without being on PPMC. If for some reason that I  
> am not qualified to contribute fully, then I will try to contribute  
> as much as possible.

Typically with Maven the release is handled almost entirely by the  
Maven release plugin. It prepares the release by inspecting your POM  
and makes sure you have no SNAPSHOT dependencies, makes sure you're  
not using any SNAPSHOT plugins, and makes sure none of your POM  
ancestry contains any SNAPSHOTs. It then creates a tag for you in  
SVN. Then you perform the release, and this can be done on the same  
machine or a separate machine, or Continuum can do it. Find a machine  
in a public space that you will use for all your releases. Using the  
Maven zones is probably a good idea. Build the release on a machine  
everyone can get access to. I've run into small glitches building  
releases on my machine. Anyway the perform operation will check out  
the tag, build, test, and deploys to a Maven repository with the  
release metadata information.

The release plugin will take care of most of the crap work. I am  
working on adding signing to the release plugin, and adding staging  
of the releases where the candidate is staged and if deemed working  
and intact is then transfered to the official release repository.

If you want to help with the release then the best thing you can do  
is evaluate the release plugin and fix anything that isn't working.

> Regards,
> Bo
> [1]

View raw message