fedpkg workflow and release numbers

Garrett Holmstrom gholms at fedoraproject.org
Sun Sep 19 16:11:48 UTC 2010


On 9/19/2010 9:40, Christoph Höger wrote:
> Hi all,
>
> since I keep offlineimap the same version for the latest stable (that I
> got my hands on) + devel versions, my fedpkg workflow looks like:
>
> 1. master>  build package
>
> 2. f14>  git pull origin master&&  fedpkg push&&  fedpkg build ...
>
> 3. f13>  git pull origin master&&  fedpkg push&&  fedpkg build ...
>
> I think this is how git should be used in that case (no difference
> between all branches). But this means taking the release number from
> step 1 through all steps (e.g. building offlineimap-6.2.0-2.fc14 without
> ever building offlineimap-6.2.0-2.fc14). Is that ok in terms of fedora
> package policies?

It sounds like you're doing more work than you have to if all the 
branches are the same.  Why not just run ``git merge'' on the other 
branches?  Here's what I generally do:

* git checkout master; <edit files>; git commit ...; git push
* git checkout f14; git merge master; git push
* git checkout f13; git merge master; git push
* (...and so on for the other branches)
* koji build --nowait dist-f15 
'git://pkgs.fedoraproject.org/<pkgname>?#199d3785f44e4f4d0005e2670b1e58179b290c95'
* koji build --nowait dist-f14-updates-candidate 
'git://pkgs.fedoraproject.org/<pkgname>?#199d3785f44e4f4d0005e2670b1e58179b290c95'
* (...and so on for the other branches)

Koji doesn't care what branch a given hash comes from since either you 
or fedpkg will specify a target when calling it, so having several 
branches at the same commit is not a problem.


More information about the devel mailing list