We are different: kernel changelog

[Jarod Wilson]

Jarod Wilson wrote:
> Michael Schwendt wrote:
>> On Mon, 9 Feb 2009 13:33:58 -0500, Dave wrote:
>>
>>> On Mon, Feb 09, 2009 at 01:27:10PM -0500, Christopher Aillon wrote:
>>>  > On 02/09/2009 01:12 PM, Dave Jones wrote:
>>>  > > On Mon, Feb 09, 2009 at 09:50:15AM -0500, Jarod Wilson wrote:
>>>  > >   > >  > For rawhide, its a bit messy and most folks don't want 
>>> to waste time  > >  > from working on code to figure out how to 
>>> determine the EVR of the hour  > >  > (granted, yes, 'make verrel' 
>>> and add one to the appropriate place is all  > >  > it is...). A fair 
>>> number of rawhide updates are done in a scripted  > >  > fashion, 
>>> guess we could add logic to the script to include an EVR.
>>>  > >  > > If bumpspecfile.py had smarts to insert the version number, 
>>> it'd be great.
>>>  > > As all the rebases, and some of the other changes are scripted 
>>> already anyway.
>>>  >  > It does.  Though not sure how it will handle the foo that 
>>> happens with  > kernel versioning.
>>>
>>> It does the right thing by trying to evaluate it, and putting what it 
>>> thinks
>>> the result is in the right place, but unfortunatly, it also bumps 
>>> Release:
>>> (Even if Release: isn't a number, but a macro)
>>> which screws things up horribly, resulting in versions like 
>>> 2.6.29-0.100.rc4.git1.1
>>>
>>
>> It does not evaluate it to bump it, though. It only does that when adding
>> the changelog entries -- and that would work fine if the script got an
>> option to "not bump". ;)
>>
>> To bump release values, it tries to recognise several types of common
>> "Release" value definitions directly in hope that they adhere to the
>> guidelines.
>>
>> With so many macros
>>
>> | %define pkg_release %{fedora_build}%{?stable_rctag}%{?buildid}%{?dist}
>> | Release: %{pkg_release}
>>
>> it would simply need to be *much* more mighty, before it could find the
>> right value to bump.
> 
> Thing is... There *is* no right value to bump. Bumps happen 
> automagically based on cvs version. So what we need is something that 
> evaluates the current version and adds one to the %fedora_build field to 
> "get it right" for the next cvs commit.

Well, I wasted way too much time on it, but I just added some changes to 
the kernel's scripts/bumpspecfile.py so that it'll add V-R to changelog 
entries for scripted updates in all the cases it recognizes. You'll 
still have to convince people its worth their time and effort to add 
them to non-scripted clog entries, at least for the rawhide case, but 
maybe they'll feel more inclined to if the prior entry is already filled 
in... Back to my actual work I go now...

-- 
Jarod Wilson
jarod at redhat.com