to bump or not to bump

Manuel Wolfshant wolfy at nobugconsulting.ro
Tue Feb 3 14:09:26 UTC 2009


Thorsten Leemhuis wrote:
> On 03.02.2009 13:27, Manuel Wolfshant wrote:
>>     I would like to hear some more opinions on the subject described 
>> in the thread started by 
>> https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is 
>> expressed in comment #9 and I am quite sure that any future update of 
>> the rawhide version might introduce the exact same problem again. 
>
> I'd tend to agree with some of what the reported outlines, but I'd say 
> it's not important enough to justify a rebuild.
>
>> I could, of course, keep using always the same release tag as in the 
>> corresponding rawhide version, but it looks a bit odd to me. 
>
> For me it's not odd; I'd even say it's the natural thing to do.
>
> Rawhide is the main "devel branch" for the spec file itself -- the 
> version-release of the spec file for me is like a verison number of a 
> regular software. Version numbers don't go backwards; thus if I'd 
> (kind of) fork a spec file by picking it from rawhide and using it for 
> another branch (EPEL in this case) then I'd normally leave the 
> version-release as it is as long as %dist gets used in %release.
>
> But if maintainers in Rawhide and EPEL are different then I'd want to 
> be on the safe site and would add a ".1" to %release and "rebuild for 
> EPEL" to the changelog -- then it's obvious where this spec file 
> exactly comes from and how they relate to each other -- that might be 
> important to know for users and packagers.
>
Maintainers are different in EPEL and rawhide. I try to sync with Ville 
before rebuilding in EPEL, but I am not going to keep his pace. My 
intention is to do as few rebuilds as sensible, integrating the 
differences accumulated over time. Current bump to 0.85 was mainly 
triggered by the release of RHEL 5.3 and integrated a few changes which 
were commited by Ville to CVS, were not yet included in any version 
built in koji but about which he told me in a private mail that might be 
good to include. Changes which were properly documented by me in the 
changelog.






More information about the epel-devel-list mailing list