I had already done a local mock build to make sure the builds worked.
To release 389-ds-base 1.2.6.rc6 and 389-admin 1.1.11.rc2, this is what I did:
yum install --enablerepo=epel-testing fedora-packagerthe one in epel stable is not that good - the one in testing is much better
fedpkg clone 389-ds-base cd 389-ds-base fedpkg new-sources /path/to/389-ds-base-1.2.6.rc6.tar.bz2 # updates 'sources' and '.gitignore' and does a git add edit 389-ds-base.spec *.sh # update for new version, bump Release, add changelog git commit -a fedpkg verrel # checks changelog consistency git tag $(fedpkg verrel) # creates a named tag like the old make tag git push --dry-run -v # to see what will happen git push # push the changes git push --tags # push the tag fedpkg build --nowaitThat takes care of master/rawhide. There is a similar workflow for the other branches (currently f14, f13, f12, el6, el5, el4) - for each branch XXX
fedpkg switch-branch XXX git merge master # this may cause merge conflicts - edit/git add/git commit to resolveedit the files - remove the conflict markers - may have to manually update release numbers, changelog comments because different branches may have been updated independently e.g. to rebuild for a new build dependency - changelog comment editing may be tricky - have to preserve the old comments and order while adding the new comment for the new version, which may have a different Release number
edit 389-ds-base.spec ... # edit all of the files that are marked as having conflicts git add 389-ds-base.spec ... # add the files to the commit to tell git merge we have fixed them git commit # will resolve the merge conflicts git log # optional - check the merge commits fedpkg verrel # checks changelog consistency git tag $(fedpkg verrel) # creates a named tag like the old make tag git push --dry-run -v origin XXX:refs/heads/XXX/master # to see what will happen git push origin XXX:refs/heads/XXX/master # push the changes git push --tags # push the tag fedpkg build --nowaitNOTES:
* not sure why git merge creates so many conflicts and cannot automatically merge - seems like it should be able to do that - perhaps subsequent merges will remember the common ancestor better and just "do the right thing"
* not sure why I have to specify git push origin XXX:refs/heads/XXX/master - in other projects, if I do
git checkout BRANCH
and BRANCH is set up to do remote tracking, doing
will just automatically push all branches that are tracked remotely - perhaps subsequent pushes will work