Hi, Kelvin. Thank you for sharing your experience as a RM.
Please see my comments inline. Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Jun 21, 2010, at 10:30 AM, kelvin goodson wrote: > Having gone through the release processs recently, and seeing all the > good improvements ant has been making to make it easier to release in > future, here are some notes on where the pain points were for me, as > input to any further improvements we may like to make. > > most of the pain was just the lenth of time it takes to issue the long > stream of commands, nurse them through their execution, verify their > correct working and iterate over subparts of the process as indicated > by the success or otherwise of any given step. With so many steps > it's also easy to make a slip > > With reference to [1] here are some specific issues > > svn:merge is unworkable due to mergeproperties all over the source > hierarchy (not sure if this has now been addresed?) Some tools such as TortoiseSVN adds extra svn properties during the merge. We can try to see if we can configure the tools to avoid that. For those already in the code base, we can run a batch script to remove them if we think they are causing confusions. > > there's a bug in signing maven artifacts which means some ended up in > the apache repo with bad signatures. There's a suggested fix I think > at [2] > > dependency artifact version checking Are you leveraging tools such as mvn dependency:tree? > > setting the branch version to <newrelease>-SNAPSHOT is good for > trapping issues, but bad for merging fixes from branch to trunk (can't > just let it a merge run, must police these changes) Are they causing conflicts during the merge? I found that that some tools are better handling the merges in the 3-way merge. > > upload speed: I wanted to do some things locally, and some things I > wanted to use a remote machine for faster artifact upload. If I recall > correctly the main things I wanted to do locally was artifact signing, > both distros and maven artifacts. Aside from not really wanting my > code signing private key on a remote machine, there were issues > importing a private key. It seemed to be bad form to do this, so much > so that the arguments on gpg to allow it seem to have been withdrawn. > > Checking the RAT reports -- now fixed I think. There's probably a > knack to doing this quickly, but I found it a bit of a chore. > > Understanding which directories to do maven deploy from > > using the maven staging plugin to copy artifacts (no pain, I just > didnt do it this way as the other way was tried and tested) > > [1] https://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Making+Releases > [2] http://people.apache.org/~henkp/repo/faq.html (Comment from > Clement Escoffier)
