FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-19-2010, 02:40 PM
Christoph Höger
 
Default 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
 
Old 09-19-2010, 03:18 PM
Michael Schwendt
 
Default 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
 
Old 09-19-2010, 04:11 PM
Garrett Holmstrom
 
Default 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
 

Thread Tools




All times are GMT. The time now is 01:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org