Simplified contribution process?

Kevin Kofler kevin.kofler at chello.at
Sat Nov 10 00:50:32 UTC 2007


Gérard Milmeister <gemi <at> bluewin.ch> writes:
> Meld is quite helpful to synchronize the different branches.

I usually just use the same specfile, with %{?fedora} conditionals when needed, 
that way there's nothing to merge. :-) Rex Dieter likes working that way too. 
Other maintainers prefer separate specfiles, which has some advantages (more 
straightforward to read, need to worry only about one branch at a time) and 
some drawbacks (merging is harder, need to worry about each branch separately).

How I personally work is that if I have to fix something quickly for a branch 
without pulling in the latest from devel (or without updating devel because 
it's going to get a new version which has the fix upstream shortly), e.g. 
during final devel freeze, I'll change the branch only and use n%{?dist}.m 
versioning. An example where I did this: strigi 0.5.5 in F8 had a build-related 
problem. The problem was already fixed upstream in 0.5.7, but I didn't want to 
pull in 0.5.7 into F8 for several reasons (freeze, worry about breaking things, 
which turned out legitimate because 0.5.7 needs a new kdelibs4 to match the API 
changes). So I built a 0.5.5-1.fc8.2 with a patch for this issue in F8 only. F7 
was not affected by the issue due to the different binutils in use (no 
build-id), and I didn't bother updating devel because I knew 0.5.7 would go 
there soon anyway, so I edited only the specfile for F8. Dropping the quick 
hack later is easy in such a case, just copy over the new specfile from devel, 
making them the same again. (Now some pedants will undoubtedly complain that 
this loses changelog entries, and in fact Deji left the extra F8 changelog 
entries in when he merged Strigi 0.5.7 from devel to F8, but I'd say the 
entries are irrelevant because the updated package is derived from a different 
branch which never got the quick hack in the first place, so I don't bother 
readding them when I do this sort of merges. There's pedantic arguments both 
for leaving the entries in or not, I simply prefer the most practical way.)

        Kevin Kofler




More information about the devel mailing list