cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bozhong Lin <>
Subject Re: what are required for contributing to release management
Date Fri, 29 Sep 2006 02:44:59 GMT
Thanks for clarification. I will definitely take a look into Maven 
release plugin.


Jason van Zyl wrote:
> 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