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