fedpkg workflow and release numbers
 

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?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

fedpkg workflow and release numbers
 

On Sun, 19 Sep 2010 16:40:16 +0200, Christoph 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?

Can't be answered. The two NEVR in your text are identical. ;-)

But: All what is important is that EVR for master > EVR for f14 > EVR for f13,
and that is true for your case when using %{?dist} in the Release tag.
Then your example will build offlineimap-6.2.0-2.fc15 > offlineimap-6.2.0-2.fc14 > offlineimap-6.2.0-2.fc13.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

fedpkg workflow and release numbers
 

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>?#199d3785f44e4f4d0005e2670b1e58179b290c9 5'
* koji build --nowait dist-f14-updates-candidate
'git://pkgs.fedoraproject.org/<pkgname>?#199d3785f44e4f4d0005e2670b1e58179b290c9 5'
* (...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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel