On Thu, 2007-08-30 at 23:29 -0500, Eric Sandeen wrote:
seth vidal wrote:
> You're right - no conclusion - but I guess I should put this to the
> packaging committee to get it added to the criteria - if we nuke
> everything but the last years worth from the %changelog and we do that
> as something useful to do for every release - then we'll be able to keep
> it pruned down and we'll still keep the history.
>
> People on the packaging committe - does that sound fair?
>
> -sv
I'm always worried about making it harder to get the history related to
the running code... (I guess there's still always cvs history, but...)
I'd like to see all changelog entries remain that are related to patches
still carried in the src.rpm - and not thrown away just because that
patch was added > 1 year ago. Much harder to automate, though... If
there's a policy that says I can trim my own changelogs with that
criteria, I'll gladly do it. (Maybe the automated trimmer could only
nuke old changelog entries if the changelog is above a certain size
threshold?)
So my first question is this: Why are we carrying a patch for >1yr?
Shouldn't it be being pushed to upstream?
My only problem with letting the changelogs be cherry picked like this
is b/c it is would be hard for people to know when to look elsewhere.
Having the changelog difference be a hard number relative to the latest
date in the package changelog would make it more consistent to know when
to look elsewhere.
Having a consistent location for what is 'elsewhere' is probably also
good.
-sv