changelogs in packages and space use
Ralf Corsepius
rc040203 at freenet.de
Fri Aug 31 05:36:48 UTC 2007
On Fri, 2007-08-31 at 00:55 -0400, seth vidal wrote:
> 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?
There are many reasons for doing so, e.g.
* dead/non-responsive upstream
* upstream has adopted patch, but hasn't released a new tarball, since.
* patches lack generality/are RH/Fedora-specific hacks.
* patches contain experimental features.
...
Ralf
More information about the fedora-devel-list
mailing list